| 01:31 | <cardona507> | anyone know any other mobile sites that are live like gmail for iPhone that are html5? |
| 03:31 | <Hixie> | if anyone has IE8 or IE9 it would be great if they could e-mail me the result of running http://www.hixie.ch/tests/adhoc/html/parsing/encoding/all.html |
| 03:31 | <Hixie> | man i wish we had microsoft people here |
| 03:32 | <abarth> | i wish IE9 had just implemented the HTML5 parsing algorithm |
| 03:32 | <abarth> | maybe next time |
| 05:06 | <Hixie> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10743 Anyone got a good idea for another example of where we have conformance criteria to avoid brittle constructs in HTML? |
| 05:07 | <Hixie> | (since we've made the one that we had as an example less brittle such that it no longer applies...) |
| 05:27 | <myakura> | agrrr “Rename the input element's @speech attribute to @webkitspeech since it is still experimental.” http://webkit.org/b/46799 |
| 05:31 | <jacobolus> | question about the svg spec, if anyone around here knows. |
| 05:31 | <jacobolus> | In the part for the V command inside a path, it says "Multiple y values can be provided (although usually this doesn't make sense). At the end of the command, the new current point becomes (cpx, y) for the final value of y." |
| 05:31 | <jacobolus> | Is there any reason at all for the multiple values of y thing with the last one superseding the rest? It seems to me that "this" *never* makes sense. |
| 05:33 | <jacobolus> | or does that imply that it'll draw a separate segment for each value of y provided? |
| 05:33 | <jacobolus> | then I could understand it maybe, if there were e.g. markers at the vertices |
| 05:34 | <Hixie> | myakura: file a bug to make it x-webkit-speech :-) |
| 05:38 | <jacobolus> | Hixie: people were joking about acid 4 earlier. will there be such a thing and is it possible to send ideas/pleas/etc? |
| 05:41 | <othermaciej> | myakura: did you file it? if not I can |
| 05:42 | <othermaciej> | I wonder if we have any other cruft we can rename |
| 05:45 | <abarth> | we should rename all experimental things every release, just to stop people from relying on it |
| 05:47 | <othermaciej> | heh |
| 05:47 | <abarth> | (that might be a bit meanspirited) |
| 05:47 | <othermaciej> | I think it would not be a win for users |
| 05:48 | <othermaciej> | I am always leery of adding too much experimental stuff because it's so easy for it to accidentally become not-so-experimental |
| 05:49 | <abarth> | btw, thanks for explaining the security issues to the hybi folks |
| 05:49 | <abarth> | you're doing a much better job than I would :) |
| 05:49 | <abarth> | the XOR with a PRNG isn't a terrible idea |
| 05:49 | <abarth> | implementing RC4 isn't that hard |
| 05:50 | <othermaciej> | things increasingly turn into poor man's TLS |
| 05:50 | <abarth> | sure |
| 05:50 | <othermaciej> | thanks for your kind words, but I am not sure I am doing such a great job of explaining |
| 05:50 | <abarth> | it improves on TLS in the sense that you don't have to waste packet bits with a MAC |
| 05:50 | <othermaciej> | I feel like I have gotten some points across, but people still get confused between the two possible directions of attack, what parties can be trusted in what situation, etc |
| 05:51 | <abarth> | the model of trusting the browser but not the code running inside the browser is tricky for folks who don't do this all the time |
| 05:51 | <abarth> | i spend a lot of time working that idea into the minds of students |
| 05:51 | <abarth> | the "don't trust the client" message is easier to understand |
| 05:52 | <othermaciej> | I find it hard to get the intuition across, since I have spent so much time now as an insider |
| 05:52 | <abarth> | part of it is just a knowledge base of "what can JavaScript inside the browser actually do" |
| 05:53 | <abarth> | vis-a-vis generating network requests (in this case) |
| 05:53 | <othermaciej> | the seductive idea of browsers passing the buck to web sites also seems to arise with regards to backwards compatibility (vs following the letter of the spec) a lot |
| 05:53 | <abarth> | e.g., setting some headers but not other |
| 05:54 | <abarth> | that's part of a more general cultural difference |
| 05:54 | <abarth> | there's a lot of places where the IETF community is happy to pass the buck |
| 05:54 | <abarth> | i don't quite understand why that is |
| 05:55 | <abarth> | i think they have more of an attachment to the aesthetic beauty of what could be |
| 05:55 | <abarth> | rather than feeling chained to what is |
| 05:55 | <othermaciej> | the lowest level protocols require a fairly rigorous treatment and maybe that spawned a culture of "doing it right" |
| 05:56 | <othermaciej> | whereas http is not nearly so foundational and is only really complicated because of accretion, not for essential reasons |
| 05:56 | <othermaciej> | also in the earliest days it was probably completely reasonable to suggest that a large proportion of all the hosts on the internet should change their software |
| 05:57 | <abarth> | i've noticed a pattern that folks tend to think that things that existed before they were paying attention are fixed whereas everything that came after can be changed |
| 05:57 | <abarth> | maybe they've just been in the game longer than us |
| 05:57 | <abarth> | so they view more as changable |
| 06:04 | <Hixie> | jacobolus: no immediate plan |
| 06:05 | <jacobolus> | okay |
| 06:05 | <jacobolus> | I guess everyone should be keeping their lists of pet bugs anyway |
| 06:06 | <jacobolus> | othermaciej: I'm amazed at your dedication to discussion in hybi. I can't even skim the subject lines without getting dizzy |
| 06:07 | <othermaciej> | jacobolus: I only did it cause jgraham asked |
| 06:08 | <othermaciej> | abarth: I'm not sure I would characterize the pattern that way |
| 06:08 | <othermaciej> | some people think specs are fixed and implementations are malleable |
| 06:08 | <jacobolus> | abarth: I don't think IETF community has any specific attachments to things. I think they just like arguing without experience or much careful thought for the sake of arguing |
| 06:09 | <jacobolus> | the proposals are certainly not "aesthetically beautiful" by any standard of beauty I would recognize |
| 06:10 | <othermaciej> | oh, there's certainly people whose enthusiasm is greater than their cluefulness |
| 06:10 | <abarth> | othermaciej: as a WebKit example, Darin and Eric think we should/could rename LayoutTests to RegressionTests whereas that never occurred to me. I attribute that to them being around when the name "LayoutTests" was picked, but I could well be overgeneralizing |
| 06:10 | <othermaciej> | but they are to some extent emulating the cultural patterns set by their tribal elders |
| 06:11 | <othermaciej> | I was around before almost anything in WebKit was picked, so I guess it's hard for me to evaluate this for myself |
| 06:12 | <othermaciej> | I mean, I guess I wouldn't advocate "start over and base on Gecko instead of KHTML", but I'd like to think that's because it would be an insane plan, not because KHTML was picked before I joined |
| 06:13 | <othermaciej> | I like to think of myself as more attached to broad principles than to specifics |
| 06:14 | <othermaciej> | so "be willing to rename if the new name is better (for names not exposed as API at least)" seems more important than any specific name |
| 06:17 | <abarth> | i think that's been healthy for the project |
| 06:17 | <abarth> | having a clearly defined API also helps |
| 06:17 | <abarth> | so its clear what's allowed to be changed wildly and what has to stay the same |
| 06:34 | <gsnedders> | 9:15am firealarms are evil. |
| 06:34 | <gsnedders> | s/9/6/ |
| 06:34 | <gsnedders> | (and a fire-drill at that) |
| 07:10 | <abarth> | Hixie: thoughts on http://code.google.com/p/chromium/issues/detail?id=54563 ? |
| 07:47 | <jgraham> | Hixie: I have often wondered why the stack of open elements isn't composed of (insertion mode, element) tuples |
| 07:48 | <jgraham> | So if that design works I see no reason to avoid it. It's a pretty scary change at this stage though |
| 07:49 | <Hixie> | abarth: (a) report it to the SVG and SMIL WGs, (b) limit the animation code to non-JS attributes by whitelisting the animatable ones |
| 07:50 | <abarth> | sounds reasonable |
| 07:50 | <Hixie> | but yeah, it's just yet more reason blacklist filters are doomed |
| 07:50 | <Hixie> | jgraham: agreed on all counts |
| 07:51 | <Hixie> | abarth: did you see the URL-related bug? |
| 07:51 | <abarth> | 10410 ? |
| 07:51 | <abarth> | i just commented on it |
| 07:52 | <abarth> | i love that every browser is different |
| 07:52 | <abarth> | at least on different parts of that test case |
| 07:52 | <abarth> | ;a just disappears for Firefox |
| 07:53 | <abarth> | etc |
| 08:00 | <Hixie> | heh |
| 08:01 | <Hixie> | abarth: how about the other way around? fragment #%23, say? |
| 08:01 | <Hixie> | does it unescape? |
| 08:03 | <abarth> | generally speaking, there are two approaches browsers take |
| 08:03 | <abarth> | IE+Chrome have a canonical representation for each character in each part of the URL |
| 08:03 | <abarth> | and they like to transform things to their canonical representation |
| 08:04 | <abarth> | Firefox+Safari on the other hand |
| 08:04 | <abarth> | like to keep things in the original form |
| 08:04 | <abarth> | but will canonicalize "problematic" characters |
| 08:04 | <abarth> | e.g., that aren't representable in a reasonably way |
| 08:04 | <abarth> | e.g., a ":" character in the scheme |
| 08:05 | <abarth> | some characters are so nutty, that the proper way to represent them in some parts of the URL is as a percent-encoded HTML entity |
| 08:05 | <abarth> | (i couldn't make this stuff up) |
| 08:06 | <abarth> | IMHO, the aggressive canonicalizing behavior is better |
| 08:06 | <abarth> | because you don't get confused by HTTP schemes when you meant http, etc |
| 08:07 | <abarth> | also, other folks who parse URLs after you are more likely to get the result you expect :) |
| 08:09 | <Hixie> | k well i guess i'll wontfix this bug on the assumption that in due course this will all become defined by your spec and i'll eventually just defer to that |
| 08:10 | <abarth> | makes sense to me |
| 08:10 | <abarth> | i need to find a good solid week to dig into this stuff and get the spec in reasonable shape |
| 08:57 | <annevk> | Hixie, hmm, I do like x-vendor-feature, I wonder what I said in that bug report |
| 08:58 | <Hixie> | heh |
| 08:58 | <Hixie> | so long as you like it, we're good. :-) |
| 08:59 | <annevk> | "I think we should reserve everything apart from x-vendor-feature." what I meant was that only x-vendor-feature should be playground for UAs, the rest should be available to whoever is in charge of HTML |
| 09:01 | <Hixie> | aah |
| 09:01 | <Hixie> | by "reserve" i meant "guarantee that we'll never use" |
| 09:01 | <annevk> | fair enough |
| 09:05 | <annevk> | Hixie, in Safari I get Windows-1252 / Windows-1254 |
| 09:05 | <Hixie> | yeah i get that on mac too |
| 09:05 | <Hixie> | dunno what he's doing |
| 09:06 | <annevk> | doesn't that mean it does not ignore escapes? |
| 09:06 | <annevk> | as he says? |
| 09:07 | <Hixie> | er wait, what do you get? |
| 09:07 | Hixie | looks again |
| 09:07 | <annevk> | I'm not on a nightly though |
| 09:08 | <Hixie> | for http://www.hixie.ch/tests/adhoc/html/parsing/encoding/113.html i get 1252/1252 for chrome and safari nightlies |
| 09:08 | <annevk> | aah, I see |
| 09:08 | <Hixie> | sorry, misread what you wrote |
| 09:08 | <annevk> | so Safari changed! |
| 09:08 | <annevk> | that is even more of an indication that I was correct |
| 09:08 | <Hixie> | i wonder if safari changed or if it's a mac/windows thing |
| 09:08 | <Hixie> | let me test older safari on mac |
| 09:08 | <annevk> | well, I have a Mac here too |
| 09:08 | <annevk> | but only stable Safari |
| 09:08 | <annevk> | 5.02 or some such |
| 09:08 | <Hixie> | wohay, yes, older safari did 1252/1254 |
| 09:09 | <Hixie> | interesting! |
| 09:12 | <annevk> | ooh, <s> is valid now |
| 09:17 | <jgraham> | I love bugs that are just statements |
| 09:17 | <jgraham> | "Sections may contain headings of any rank |
| 09:17 | <jgraham> | " |
| 09:17 | zcorpan | updated html5-elements |
| 09:18 | <hsivonen> | it'll be interesting to see what happens if Julian and Leif disagree on <s> |
| 09:19 | <Hixie> | heh |
| 09:27 | <Hixie> | othermaciej: i'm confused. i thought the ARIA change for 'grid' was that HTML <table> elements, etc, no longer were considered examples of those. But the spec linked to in the bug still lists HTML table as being the "base concept" for 'grid'? |
| 09:27 | <othermaciej> | Hixie: "base concept" apparently is supposed to mean "sort of resembles this other thing" rather than "this other thing is an example of fulfilling this role" |
| 09:28 | <Hixie> | o_O |
| 09:28 | <othermaciej> | "base concept" strikes me as a fuzzy concept |
| 09:28 | <hsivonen> | Hixie: <table> is a table and <table role=grid> is semantically like <datagrid>, AFAICT |
| 09:28 | <othermaciej> | the thing they actually changed is that the grid role is now defined as only referring to an interactive grid control |
| 09:29 | <Hixie> | hsivonen: can you quote where in ARIA it says that? |
| 09:29 | <Hixie> | othermaciej: in an AT, a <table> is an interactive control |
| 09:29 | <Hixie> | othermaciej: so...? |
| 09:29 | <Hixie> | othermaciej: i'm confused |
| 09:29 | <hsivonen> | Hixie: this is the understanding I have inferred from extensive tea leaf reading over time. I'm not looking at the ARIA spec right now. |
| 09:30 | <othermaciej> | "A grid is an interactive control which contains cells of tabular data arranged in rows and columns, like a table." |
| 09:30 | <Hixie> | hsivonen: k. I'm trying to work out what the spec actually says, rather than what they meant it to say. I find the latter to lead to even more pain than the former. |
| 09:30 | <othermaciej> | you could argue that AT makes absolutely everything "interactive", but that would be a silly inference in context |
| 09:30 | <Hixie> | othermaciej: sounds exactly like what an AT does with <table> to me. |
| 09:30 | <hsivonen> | Hixie: IIRC, I have outstanding LC comments on ARIA regarding whether <table role=grid> should imply role=gridcell on every <td> in that table |
| 09:30 | <othermaciej> | yes, but the role is supposed to be about what the non-AT semantics are |
| 09:31 | <othermaciej> | so they can be exposed to AT |
| 09:31 | <Hixie> | othermaciej: i thought ARIA was about what ATs did |
| 09:31 | <othermaciej> | ARIA is about expressing how the content behaves in a way that AT can see and act upon |
| 09:31 | <Hixie> | othermaciej: if an AT treats a table and an interactive grid in the same way, why would they have different roles? |
| 09:31 | <hsivonen> | Hixie: I gather the idea is that non-interactive tables and interactive datagrids would be exposed differently to AT |
| 09:32 | <othermaciej> | apparently at least some accessibility APIs expose data tables and interactive grid controls (datagrid type things) in different ways |
| 09:32 | <hsivonen> | I have absolutely no idea if they actually *are* in existing implemetations |
| 09:32 | <Hixie> | what could the difference be? |
| 09:32 | <othermaciej> | I believe they are the same role in Mac OS X / iOS accessibility APIs |
| 09:32 | <Hixie> | i'm honestly curious |
| 09:33 | <Hixie> | so ARIA can't represent non-interactive grids? |
| 09:33 | <hsivonen> | Hixie: right. you'd use plain old HTML tables for those |
| 09:33 | <Hixie> | just like you'd use a plain old HTML heading for a heading? |
| 09:33 | <Hixie> | but they still have role=heading? |
| 09:33 | <hsivonen> | Hixie: right |
| 09:33 | <Hixie> | ARIA makes less and less sense the more i try to apply it |
| 09:34 | <hsivonen> | Hixie: someone might make a heading out of <div>s but only hard-core "tables are evil" folks make non-interactive tables out of <div>s |
| 09:35 | <Hixie> | someone making a heading out of <div>s is not writing conforming html |
| 09:36 | <hsivonen> | Hixie: ARIA is about putting duct tape on HTML as practiced--not only as conforming |
| 09:36 | <Hixie> | and why would they make interactive tables out of divs but not non-interactive ones? |
| 09:36 | <jgraham> | Really if you are making a heading out of <div>s the chance of you being clueful enough to use aria seem slim |
| 09:36 | <hsivonen> | Hixie: I don't know why role=gridcell exists |
| 09:36 | <hsivonen> | Hixie: but you'd make interactive grids out of <table> |
| 09:37 | <hsivonen> | Hixie: hence <table role=grid> |
| 09:37 | <Hixie> | well i sure hope web authors can make head or tail of this |
| 09:37 | <hsivonen> | jgraham: see http://diveintomark.org/archives/2009/03/21/accessibility-is-a-harsh-mistress |
| 09:37 | <hsivonen> | jgraham: also, see GWT |
| 09:38 | <hsivonen> | Hixie: sola scriptura doesn't work here, you need to consider the tradition for context |
| 09:39 | <Hixie> | nevermind |
| 09:39 | <othermaciej> | from what I can tell, UIA is the only accessibility API to distinguish between grids and tables |
| 09:39 | <Hixie> | i've moved on |
| 09:39 | <annevk> | jgraham, but expensive IBM consultants will do it for you! |
| 09:39 | <annevk> | jgraham, it's great |
| 09:40 | <othermaciej> | out of reasonably popular ones |
| 09:41 | <othermaciej> | I think the notion of interactivity is vaguely believed to be about keyboard navigability, though that is not a device-independent distinction -- it makes no sense on systems that the multitouch UI paradigm instead of mouse/keyboard |
| 09:41 | <othermaciej> | GMail is almost completely made out of <div>s |
| 09:41 | <othermaciej> | except for the occasional stray <span> or <a> |
| 09:42 | <othermaciej> | looking at GMail with the Web Inspector makes me cry with sad |
| 09:47 | <jgraham> | hsivonen: GWT generates aria? |
| 09:49 | <Hixie> | abarth, othermaciej: any comment on http://www.w3.org/Bugs/Public/show_bug.cgi?id=10625#c6 from a webkit perspective? |
| 09:49 | <hsivonen> | jgraham: I gather it does. |
| 09:50 | <othermaciej> | Hixie: I think <https://bugs.webkit.org/show_bug.cgi?id=43328>; says it all - we'd like some behavior that doesn't lead to that regression, which to my limited understanding the spec does not exactly forbid but does not require either |
| 09:50 | <Hixie> | k |
| 09:50 | <jgraham> | hsivonen: Wow. I thought that there was no new badness to discover about GWT |
| 09:51 | <jgraham> | (assuming it uses ARIA instead of, rather than in addition to, good HTML) |
| 09:51 | <othermaciej> | jgraham: given that it's making <div> soup, I don't think ARIA counts as net marginal badness |
| 09:52 | <jgraham> | othermaciej: If it has the information needed to write useful aria, it presumably also has the information needed to use the correct elements |
| 09:52 | <othermaciej> | jgraham: I do wonder about that |
| 09:52 | <othermaciej> | not just for GWT but for other also clearly autogenerated div soup UIs like GMail |
| 09:53 | <othermaciej> | is custom styling of <button> interoperable enough that you could use it in place of <div role=button>, without incurring cross-browser compat headaches? |
| 09:53 | <othermaciej> | I don't actually know |
| 09:53 | <jgraham> | Maybe form controls are harder |
| 09:53 | <jgraham> | But headings are gimmes |
| 09:55 | <othermaciej> | GMail has some <span role=link> |
| 09:55 | <othermaciej> | that just seems like needless self-torture |
| 09:56 | <jgraham> | That's just sad |
| 09:56 | <jgraham> | I heard an unverified rumor that facebook uses <u href> |
| 10:01 | <zcorpan> | jgraham: looking around on a few random pages on facebook, javascript:alert(document.getElementsByTagName('u').length) gives 0 |
| 10:02 | <jgraham> | zcorpan: Hmm, maybe I misunderstood |
| 10:02 | <jgraham> | Or it could be mobile facebook or something |
| 10:03 | <zcorpan> | yeah, i see <u href> on touch.facebook.com |
| 10:03 | <jgraham> | hsivonen: BTW did you have any thoughts on Hixie's idea of making the stack of open elements hold the insertion mode? |
| 10:03 | <Hixie> | i don't plan on actually doing it btw |
| 10:03 | <jgraham> | Hixie: Oh, that's sad |
| 10:03 | <Hixie> | it was just as idea of what we could do on the long term if we ever decided to revamp how we wrote the spec |
| 10:04 | <Hixie> | it's possible that it would work better as an implementation strategy though |
| 10:04 | <Hixie> | it would make the 'reset' algorithm O(1) |
| 10:04 | <jgraham> | Hixie: It feels like it might fix up lots of the scary stuff around foreign content |
| 10:04 | <Hixie> | at the cost of making the stack more expensive |
| 10:04 | <jgraham> | You would still need the reset algorithm for fragment parsing |
| 10:04 | <Hixie> | i just rewrote the foreign content section to be less scary (without changing it normatively, i hope) |
| 10:05 | <Hixie> | yeah you'd need to reset once at the start, but that's O(1) also |
| 10:05 | <Hixie> | since the stack is more or less empty then |
| 10:05 | hsivonen | considers whether to escalate http://www.w3.org/Bugs/Public/show_bug.cgi?id=10589 into an ISSUE |
| 10:05 | <jgraham> | True |
| 10:06 | <Hixie> | anyway the foreign content section isn't anywhere near as bad now |
| 10:06 | <jgraham> | Hixie: I guess I will look at it to decide that :) |
| 10:06 | <Hixie> | (it's still not what hsivonen wants, but it's better than what it was, imho) |
| 10:06 | <othermaciej> | hsivonen: I don't agree with the resolution but I'm not gonna escalate it myself |
| 10:07 | <hsivonen> | jgraham: my thought about having the stack hold the insertion mode is that it's not an optimization the spec should make |
| 10:07 | <jgraham> | hsivonen: Why optimisation? It feels like the right mental model |
| 10:07 | <hsivonen> | Hixie: what's the most appropriate bug to dump my thoughts about the modeness of "in foreign" into? |
| 10:08 | <hsivonen> | jgraham: I think the right mental model is first checking if the current node isn't in the HTML namespace and doing what's now in the in foreign mode |
| 10:08 | <hsivonen> | and if the current node is in the HTML namespace, doing all the insertion mode stuff |
| 10:09 | <jgraham> | hsivonen: It doesn't only help for that case though |
| 10:09 | <Hixie> | hsivonen: a new one probably |
| 10:09 | <hsivonen> | jgraham: I'm not sure what case we are talking about? |
| 10:09 | <jgraham> | foreign content |
| 10:09 | <hsivonen> | I don't know what problem is being solved |
| 10:09 | <jgraham> | Unless I am missing something it mostly eliminates the "reset the insertion mode" |
| 10:09 | <jgraham> | stuff |
| 10:10 | <hsivonen> | jgraham: I'm open to remembering the insertion mode on stack |
| 10:10 | <hsivonen> | jgraham: I think it might even be a good thing |
| 10:10 | <hsivonen> | jgraham: my main concern is that Hixie is resisting the de-mode-ification of "in foreign" on optimization grounds |
| 10:10 | <hsivonen> | and having it as a mode has already resulted in a number of egde case bugs |
| 10:11 | <jgraham> | I generally agree that the spec shouldn't worry too hard about optimisation |
| 10:11 | <hsivonen> | jgraham: so before I support remembering the mode, I want to know if it's solving something other than letting "in foreign" continue to be a mode |
| 10:14 | <hsivonen> | Hixie: fwiw, I think <p><figure> is like <p><table> all over again |
| 10:14 | <Hixie> | the remembering the mode thing doesn't really have anything to do with foreign stuff |
| 10:14 | <Hixie> | it just gets rid of the reset algorithm |
| 10:14 | <Hixie> | while parsing |
| 10:14 | <hsivonen> | Hixie: and in the <p><table> case we now have a comment in the spec source saying you hate yourself because of it |
| 10:14 | <Hixie> | (it's entirely an optimisation) |
| 10:15 | <Hixie> | hsivonen: what i hate myself for is that it's a quirk |
| 10:15 | <Hixie> | hsivonen: if i were designing the language from scratch it wouldn't be a quirk and would always close <p> |
| 10:15 | <hsivonen> | Hixie: If I were designing the language from scratch, <p> would never autoclose |
| 10:16 | <Hixie> | i don't understand why we'd want inline <figure>s or <table>s, but especially <figure>s |
| 10:16 | <Hixie> | i'm not worried about the autoclosing behaviour so much as the content model |
| 10:16 | <othermaciej> | if you were designing from scratch, would you make <ul> close <p>? |
| 10:16 | <hsivonen> | Hixie: authors regularly try to put tables inside paragraphs. Priority of constituencies. |
| 10:16 | <Hixie> | the autoclosing behaviour is nothing but a function of the content model |
| 10:16 | <Hixie> | othermaciej: dunno, maybe. I probably wouldn't use SGML-like syntax in the first place. |
| 10:16 | jgraham | agrees with hsivonen fwiw |
| 10:16 | <jgraham> | Hardcoding this stuff into the parser just seems bad |
| 10:16 | <Hixie> | hsivonen: intentionally, or because of the quirk? |
| 10:17 | <othermaciej> | but people do put inline lists in paragraphs, and it's lame that you can't mark them up as such |
| 10:17 | <jgraham> | Because you can never ever change it again |
| 10:17 | <hsivonen> | Hixie: intentionally and then they find out HTML parsing in the standards mode doesn't let them |
| 10:17 | <hsivonen> | Hixie: well, find out after they have whined on www-validator |
| 10:17 | <Hixie> | we had this in xhtml5 for a while, and people complained |
| 10:17 | <Hixie> | so... |
| 10:18 | <Hixie> | like i said, my main concern is the content model |
| 10:18 | <othermaciej> | for <figure> it seems sensible to have a figure in a paragraph that is floated left or right, or displayed a la inline-block |
| 10:18 | <hsivonen> | Hixie: wasn't the complaint there about HTML and XHTML differing? |
| 10:18 | <Hixie> | if figure is flow, not phrasing, then it has to close <p> or the syntax just becomes incomprehensibly quirky. |
| 10:18 | <othermaciej> | unless you would argue that an image + caption combination in such a context is not a figure |
| 10:19 | <Hixie> | othermaciej: if it's not actually inline, what's the point of putting it inlien in the markup? just have it before or after the <p> |
| 10:19 | <hsivonen> | Hixie: I'd expect implicit </p> to already be incomprehensibly quirky for most people who aren't regulars on this channel |
| 10:20 | <jgraham> | Hixie: Authors don't understand flow vs phrasing. They just try to do stuff and get surprised when it breaks |
| 10:22 | <Hixie> | i do not believe that people are putting <figure>s in the middle of their paragraphs and floating them and then wondering why there's a line break. |
| 10:23 | <hsivonen> | Hixie: around 2002ish, I worked around the lack of figure by creating one from <span>s, not <div>s, precisely to get the floating I wanted |
| 10:23 | <Hixie> | what difference would span vs div do to floating?? |
| 10:24 | <hsivonen> | Hixie: the alignment with the text in the paragraph when the paragraph has margin/padding/border |
| 10:24 | <Hixie> | just stick a div around it |
| 10:24 | <hsivonen> | Hixie: srly? |
| 10:24 | <Hixie> | "srly? |
| 10:24 | <Hixie> | s/y\?/y"?/ |
| 10:25 | <hsivonen> | Hixie: you are suggesting adding divs in order to work around a problem you are creating? |
| 10:25 | <Hixie> | no i'm suggesting adding divs to get the effect you want with margin collapsing |
| 10:26 | <Hixie> | whereas you are suggesting corrupting the content model because you want to achieve a particular presentational effect |
| 10:26 | <Hixie> | (one can spin this both ways! ;-) ) |
| 10:27 | <hsivonen> | Hixie: what if the float is higher than one para? where should divs go? |
| 10:27 | <hsivonen> | http://fimug.fi/mugi-illoista |
| 10:27 | <hsivonen> | there's an example of <span>s I coded long ago |
| 10:28 | <Hixie> | you really don't think having the span as the first child of the <p> is a hack on that page? |
| 10:28 | <Hixie> | it's so glaringly wrong to me |
| 10:29 | <hsivonen> | Hixie: it's right for the CSS formatting model |
| 10:29 | <hsivonen> | which is the model we have |
| 10:29 | <Hixie> | (re your question, the height doesn't matter - you just need to have the div contain the figure and the first p after the figure) |
| 10:30 | <Hixie> | we shouldn't screw up HTML's content model and parser just to work around a quick of the CSS margin collapsing rules that can pretty easily be fixed in a future version |
| 10:30 | <hsivonen> | Hixie: when the div interferes with p following p selectors and/or margin collapsing |
| 10:30 | <jgraham> | Different question: Did the tokenizer always not emit a tag token for '<img href="foo' or is that a recent change? |
| 10:30 | <hsivonen> | jgraham: if EOF happens inside the tag, the token hasn't been emitted for quite some time |
| 10:30 | <annevk> | it's been that way for a while I think |
| 10:30 | <Hixie> | instead of asking for a change to HTML, ask for a change to CSS -- add keyword 'flush-next' or some such to 'margin-top' which causes the margin to grow so as to have a border-top equal to the border-top of the next element in the margins from which the element has been removed from flow |
| 10:31 | <zcorpan> | jgraham: i think that changed about a year ago or so |
| 10:31 | <jgraham> | That's what I thought |
| 10:31 | <jgraham> | Hmm |
| 10:31 | <Hixie> | (hard to express in english, but pretty simple in css terms) |
| 10:31 | <jgraham> | Maybe there wasn't a test for the attribute case before |
| 10:31 | <Hixie> | hsivonen: you're like a man with a hammer, and your hammer is the parser. :-) we can change more parts of the web platform than just html |
| 10:32 | <Hixie> | https://bugs.webkit.org/show_bug.cgi?id=46873#c3 is interesting, re x-foo-bar |
| 10:32 | <hsivonen> | Hixie: I'd rather not whack authors with the hammer when legacy behavior doesn't require <figure> to close <p> |
| 10:32 | jgraham | still really dislikes adding new elements to the list of ones with magic behaviour in the parser |
| 10:33 | <Hixie> | hsivonen: as noted above, i'm not really interested in the issue of the parser here, imho what the parser does is entirely a function of the content model |
| 10:33 | <annevk> | since <figure> is block it makes sense to me |
| 10:33 | <annevk> | right, what Hixie just said |
| 10:33 | <Hixie> | hsivonen: if <figure> is not phrasing content, then it should close <p>, it's just asking for bugs otherwise |
| 10:33 | <Hixie> | and if it isn't, then it shouldn't, obviously |
| 10:34 | <hsivonen> | I'll try to cool off for a few hours before I decide whether I escalate. |
| 10:34 | <Hixie> | (and should be scoping, since it can contain <p>... but that's another reason imho it shouldn't be allowed in <p>) |
| 10:34 | <othermaciej> | Hixie: indeed - doesn't seem so great to apply the pattern to event handler attributes |
| 10:34 | <hsivonen> | Hixie: I think hardcoding content models into the parser is a mistake when legacy doesn't require it |
| 10:35 | <Hixie> | hsivonen: if </p> has an optional end tag, it has an optional end tag; as bad as optional end tags are, they're even worse if they're not optional based on what the following sibling is. |
| 10:35 | <annevk> | hsivonen, so you think <section> should not imply </p>? what about </section>? |
| 10:35 | <annevk> | hsivonen, what about <datalist> and <option>? |
| 10:36 | <jgraham> | </section> popping to the nearest ancestor <section> seems entirely different |
| 10:36 | <Hixie> | if anyone has an idea for https://bugs.webkit.org/show_bug.cgi?id=46873#c3, please file a bug |
| 10:36 | <Hixie> | i have to go to bed now |
| 10:36 | <Hixie> | i'll let anne take over :-) |
| 10:36 | <Hixie> | nn |
| 10:36 | <jgraham> | I could live with <section> not closing <p> |
| 10:36 | <annevk> | o_O |
| 10:36 | <hsivonen> | annevk: I think making section close <p> doesn't close any realistic doors |
| 10:37 | <hsivonen> | annevk: but it's pretty bogus in terms of Degrade Gracefully |
| 10:38 | <annevk> | Hixie, for event handler attributes I think on<vendor><feature> makes sense |
| 10:38 | <annevk> | Hixie, even for normal attributes maybe <vendor><feature> makes sense, especially if the IDL attributes are <vendor><Feature> |
| 10:38 | <othermaciej> | it should match the event name, so assuming that's <vendor><feature>, I think that's the right suggestion |
| 10:39 | <hsivonen> | on-x-webkit-foo |
| 10:39 | <othermaciej> | (of course, it is kind of awkward for the prefix to have no punctuation, when event names are often all-lowercase |
| 10:39 | <othermaciej> | hsivonen, even if the event is named webkitfoo? |
| 10:39 | <hsivonen> | othermaciej: good point |
| 10:40 | <othermaciej> | or are you suggesting a change of convention for experimental/proprietary event names as well? |
| 10:40 | <annevk> | unless we get weird vendor names I do not think this matters much |
| 10:40 | <annevk> | ms/moz/o/webkit are all prefixes we are probably not going to use |
| 10:40 | <hsivonen> | othermaciej: I withdraw my suggestion |
| 10:40 | <annevk> | so I think we do not need x- for <vendor>-<feature> attributes either prolly |
| 10:42 | <zcorpan> | annevk: 'o' as a prefix without punctuation seems likely to clash |
| 10:42 | <zcorpan> | annevk: e.g. there's an attribute called 'open' |
| 10:42 | <zcorpan> | what if opera wants a 'pen' attribute |
| 10:42 | <annevk> | o-pen |
| 10:42 | <annevk> | oPen |
| 10:42 | <annevk> | both different |
| 10:42 | <zcorpan> | oh, with a dash |
| 10:43 | <annevk> | and we could use opera for HTML and events |
| 10:43 | <annevk> | I think we might do that already |
| 10:43 | <zcorpan> | well, we'll just have to convince the future Data and Aria browsers to use a different name for their prefixes :P |
| 10:44 | <annevk> | that should be no problem |
| 10:45 | <jgraham> | I like the x- |
| 10:45 | <jgraham> | I think it conveys a sense of danger |
| 10:45 | <jgraham> | Which is fitting in the circumstances |
| 10:46 | <zcorpan> | why is there no x in IDL extensions? |
| 10:47 | <annevk> | yeah, if it's not in the IDL it makes no sense to have it in markup |
| 11:03 | <MikeSmith> | it'd be useful to get the RDFa WG some comments on the current RDFa API spec - |
| 11:03 | <MikeSmith> | http://www.w3.org/TR/2010/WD-rdfa-api-20100923/ |
| 11:04 | <MikeSmith> | which just went to FPWD a few days ago |
| 11:06 | <MikeSmith> | actually, it seems to have already been published as a FPWD in June |
| 11:07 | <MikeSmith> | but an updated WD was just published on the 23rd |
| 11:07 | <annevk> | but we don't want to implement RDFa |
| 11:07 | <annevk> | it's like giving comments on XHTML2 |
| 11:08 | <MikeSmith> | http://www.w3.org/TR/2010/WD-rdfa-api-20100923/#sotd |
| 11:08 | <MikeSmith> | did XHTML2 have any APIs? |
| 11:09 | <MikeSmith> | are we implementing the Microdata API in browsers? |
| 11:09 | <annevk> | we probably will |
| 11:09 | <MikeSmith> | really? |
| 11:09 | <annevk> | I saw Gecko bug on it too |
| 11:09 | <MikeSmith> | why? |
| 11:09 | <MikeSmith> | hmm |
| 11:09 | <annevk> | with patches |
| 11:10 | <MikeSmith> | they will probably get patches for the RDFa API as well |
| 11:10 | <annevk> | sure, they got patches for XForms too |
| 11:14 | <MikeSmith> | https://lists.webkit.org/pipermail/webkit-dev/2010-September/014544.html |
| 11:14 | <MikeSmith> | "New Rich Text Editing Test suite" |
| 11:14 | <MikeSmith> | for contentEditable |
| 11:15 | <MikeSmith> | http://www.browserscope.org/richtext2/test |
| 11:16 | <MikeSmith> | hey, a frames-based layout |
| 11:22 | <hsivonen> | MikeSmith: the microdata API patches are from David Zbarsky, so it's a bit different from general "getting patches" |
| 11:24 | <hsivonen> | MikeSmith: that is, at least his other bugs are more coordinated than someone just showing up with patches. |
| 11:24 | <MikeSmith> | ok |
| 11:24 | <MikeSmith> | I don't know David… is he related to Boris? |
| 11:25 | <hsivonen> | MikeSmith: they are brothers |
| 11:26 | <MikeSmith> | ah OK |
| 11:30 | <annevk> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=10806 -- I wonder how Julian plans on getting this past CR |
| 11:31 | <annevk> | He's just process-trolling; not actually helping getting this resolved to his satisfaction in any way :/ |
| 11:36 | <MikeSmith> | we want to do DOM Range in WebApps, right? |
| 11:37 | <smaug____> | certainly not in whatwg |
| 11:40 | <smaug____> | I wonder if webapps could do DOM Range 2, 2nd revision or something |
| 11:40 | <smaug____> | which would be just re-writing the spec without any functional changes |
| 11:40 | <smaug____> | (Opera and Webkit probably object that because they don't conform with range anyway) |
| 11:45 | <annevk> | we don't? |
| 11:46 | <smaug____> | the acid3 thingie |
| 11:46 | <annevk> | what thingie? |
| 11:46 | <smaug____> | acid3 allows non-conforming handling |
| 11:46 | <annevk> | a new revision should have at least the Gecko proprietary extensions everyone copied |
| 11:47 | <smaug____> | the extensions could go to Range 3 |
| 11:47 | <smaug____> | or perhaps we don't need range 2, 2nd revision |
| 11:48 | <smaug____> | but it might take long enough to just re-write range 2 |
| 11:48 | <smaug____> | range 3 could be done in the same time |
| 11:49 | <smaug____> | similar to what happens with XHR 1&2 |
| 12:05 | <annevk> | lets not take xhr 1&2 as example for anything |
| 14:09 | <morelli> | hi is the pubdate attribute on time element is suposed to be empty or not or what :D ? |
| 16:41 | <TabAtkins> | It's a boolean attribute, so it doesn't need to have a value in HTML. In XHTML, write it as pubdate="pubdate". |
| 16:41 | <TabAtkins> | D'oh. Didn't check beforehand when that question was asked, or if the asker was still around. ;_; |
| 16:41 | <KaOSoFt> | ._: |
| 16:41 | <KaOSoFt> | ._. |
| 17:12 | <TabAtkins> | KaOSoFt: I prefer your 3-eyed mutant. |
| 17:13 | <Workshiva> | Don't be so geneist |
| 17:28 | <TabAtkins> | Also, I don't know why everyone doesn't just switch to RDFa5 http://www.xanthir.com/rdfa5.html |
| 17:31 | <MikeSmith> | that page is unsatisfying |
| 17:31 | <MikeSmith> | it lacks an invisible metadata of any kind at all |
| 17:32 | <MikeSmith> | let alone mineable invisible metadata |
| 17:32 | <TabAtkins> | I ensure that all metadata is visible, and non-meta. |
| 17:32 | <MikeSmith> | actually, I've coined a new acronym |
| 17:32 | <MikeSmith> | MUM |
| 17:32 | <MikeSmith> | = mineable Un-visible metadata |
| 17:33 | <TabAtkins> | Keep MUM about it? |
| 17:33 | <MikeSmith> | see, you like it already |
| 17:33 | <MikeSmith> | it's catching on quickly |
| 17:33 | <TabAtkins> | If this rate keeps up, it'll be an international phenonemon in less than a month. |
| 17:35 | <MikeSmith> | and the royalty checks will start pouring in |
| 17:36 | <MikeSmith> | and I can use the money to invest in my new business idea |
| 17:36 | <MikeSmith> | which is hush-hush for now |
| 17:36 | <Anti-X> | that page uses uppercase tags, which makes me want to shoot them in the face |
| 17:36 | <TabAtkins> | Blame the browser that saved the HTML for me. |
| 17:36 | <MikeSmith> | but just to give a clue, my business idea involves a combination of Segway and parachute |
| 17:36 | <Anti-X> | i'll shoot you in the face then? |
| 17:37 | <Anti-X> | let me just get started first.. *opens porn* |
| 17:37 | <TabAtkins> | Anti-X: No, shoot Chrome in the face. Which I suppose involves shooting me in the face, yes. |
| 17:37 | <TabAtkins> | Also: eww. |
| 17:37 | <Anti-X> | you know you like it |
| 17:37 | <Anti-X> | ... better than a real shooting |
| 17:38 | <TabAtkins> | I suppose so, yes, but that's like one of those questions you ask each other when you're drunk - "Would you rather X or Y" - and then either answer makes you weird because you have to explain it. |
| 17:38 | <TabAtkins> | Anyway, I'm out for a bit. |
| 17:45 | <Anti-X> | yeah except i'm not drunk, so it's not like that at all |
| 17:45 | <Anti-X> | :P |
| 17:51 | <Philip`> | AryehGregor: dvcs.w3.org seems to be working again |
| 18:04 | <MikeSmith> | systems team has been doing some kind of migration on dvcs.w3.org and test.w3.org |
| 18:04 | <MikeSmith> | I'm not sure if they are completely done yet |
| 18:04 | <MikeSmith> | so you might notice other problems in the mean time |
| 18:06 | <Philip`> | I noticed that the changelog Atom entries all got duplicated |
| 18:06 | <Philip`> | but otherwise it seems okay so far |
| 18:07 | <MikeSmith> | ok |
| 19:02 | <loucapo> | hey annevk, thanks again for the help the other day |
| 20:00 | <loucapo> | hey does anyone here know why cross-origin xmlhttpreq in chrome/safari are workign fine but FF3.x and 4 are barking about it? |
| 20:23 | <jacobolus> | loucapo: https://developer.mozilla.org/En/HTTP_Access_Control |
| 20:23 | <jacobolus> | is that what you're asking for? |
| 20:25 | <jacobolus> | loucapo: here are some examples http://arunranga.com/examples/access-control/ |
| 20:26 | <loucapo> | perhaps, though I thought i had it working. will read this, thanks. |
| 20:41 | <Peter-> | http://news.cnet.com/8301-30685_3-20018146-264.html |
| 20:41 | <Peter-> | Following a video format.. an image format |
| 20:41 | <Peter-> | "Google offers JPEG alternative for faster Web" |
| 20:48 | Philip` | wonders why anyone would care about that |
| 20:48 | <Philip`> | since JPEG is basically good enough |
| 20:49 | <espadrine> | Especially if the world is leaning towards massive use of video, which is far more memory-consuming. |
| 20:51 | <Rik`> | Philip`: is there any technology that stays good enough ? |
| 20:53 | <Philip`> | Lots of technology stays good enough to not be worth the effort of upgrading the entire world |
| 20:54 | <Rik`> | name one :) |
| 20:54 | <espadrine> | JPEG XR |
| 20:55 | <Philip`> | HTML |
| 20:55 | <Rik`> | HTML has evolved |
| 20:55 | <Philip`> | Everything evolves |
| 20:56 | <Philip`> | (including JPEG) |
| 20:56 | <Dashiva> | HTML... never changes |
| 20:57 | <espadrine> | Although JPEG2000 didn't gain much usage share, did it? |
| 20:58 | <Philip`> | About zero |
| 20:58 | <Philip`> | because JPEG was good enough |
| 20:58 | <Rik`> | or because it hasn't been implemented |
| 20:59 | <espadrine> | It depends on how amazingly awesome the new stuff is, I suppose. |
| 20:59 | <espadrine> | If there is a wow factor, people adopt it. |
| 21:00 | <gsnedders> | And also people are more likely to spend more time implementing it better |
| 21:53 | <Rik`> | http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html |
| 21:54 | <Rik`> | improving 65% of a page by 39% seems pretty good to me |
| 21:55 | <Rik`> | plus transparency in a future update |
| 21:56 | <Rik`> | this part seems pretty interesting |
| 21:58 | <aho> | oh boy oh boy |
| 22:02 | <aho> | i'm disappointed that they didn't add transparency right away |
| 22:02 | <aho> | the web really needs some lossy true color image format with support for transparency |
| 22:02 | <aho> | if it's something photo based, png32 is just too f-ing huge |
| 22:03 | <Philip`> | Rik`: They say they saved an average 39% on a collection of JPEG/PNG/GIF images without "perceptibly" affecting quality |
| 22:04 | <Philip`> | which seems a pretty useless number if I'm interpreting it right |
| 22:04 | <Philip`> | because one person might have a photo saved as a 5MB PNG and they'd get huge compression improvements by encoding even as plain old JPEG |
| 22:05 | <aho> | Philip`, check the gallery: http://code.google.com/speed/webp/gallery.html |
| 22:05 | <Rik`> | yes, that only says "if everyone uses webp instead of what they're doing now, we'll save 39%" |
| 22:06 | <Philip`> | It'd be more useful if they did comparisons against JPEG re-encoding with equivalent quality loss, and against the dozens of other JPEG-but-slighty-better formats that exist |
| 22:07 | <Rik`> | they did the first one |
| 22:08 | <jacobolus> | is there a list of SVG tests someplace? |
| 22:08 | <jacobolus> | that wants tests added? |
| 22:08 | <aho> | ye, a comparison with jp2 and jpg xr would have ben nice |
| 22:08 | <Philip`> | Rik`: Where? |
| 22:08 | <aho> | +e |
| 22:09 | <aho> | well, in about 10 years we can use jp2 :> |
| 22:09 | <Rik`> | the link aho posted |
| 22:09 | <jacobolus> | safari apparently currently supports marker-start, marker-mid, marker-end, but not marker as attributes on paths |
| 22:11 | <Philip`> | Rik`: That says they're comparing against JPEG originals (which might have stupid compression settings), not against re-encoded JPEGs |
| 22:13 | <Philip`> | Rik`: e.g. they claim 76% improvement on http://code.google.com/speed/webp/images/2.jpg, but if I just save it as a JPEG in Gimp then I can get 76% improvement without it looking much different |
| 22:15 | <jacobolus> | Rik`, Philip`: the webp images seem to have their color profiles stripped? |
| 22:16 | <jacobolus> | espadrine: JP2 is used a lot by people archiving very large images |
| 22:16 | <jacobolus> | it's just not used by consumer-facing web apps |
| 22:17 | <Philip`> | (The fact you can get a big improvement by just recompressing as marginally lower quality JPEG indicates that most people don't care about image size anyway) |
| 22:17 | <jacobolus> | decoders for JPEG 2000 are much much slower than decoders for JPEG |
| 22:18 | <jacobolus> | Philip`: or it indicates that grabbing the originals uploaded to wikipedia is a bad way to find compressed images |
| 22:18 | <jacobolus> | I believe the wikipedia thumbnails are reasonably compressed. the originals should be as high quality as possible IMO |
| 22:19 | <jacobolus> | because you never know what someone might want to do with them, and they won't be served to article page viewers |
| 22:19 | <annevk> | ah, WebP is out |
| 22:19 | <annevk> | and my inbox is full of bugmail yay |
| 22:20 | <Philip`> | Are there better benchmarks of WebP anywhere that I'm missing? |
| 22:20 | <jacobolus> | also, if google wants to use the lena image, they should just ask playboy; the magazine hasn't had any problem in the past with its use |
| 22:21 | <annevk> | "<video> element needs to support some form of parental control solution" whoa |
| 22:21 | <annevk> | lets boil the ocean |
| 22:21 | <aho> | the internet is AO rated |
| 22:21 | <Philip`> | Better add parental controls to <img> first |
| 22:22 | <jacobolus> | using webp for images seems to me like a really stupid thing to be pushing |
| 22:22 | <jacobolus> | I guess they want to hype the video format? |
| 22:22 | <annevk> | John Foliot is also asking for DRM |
| 22:23 | <annevk> | fun times |
| 22:23 | <aho> | lol :> |
| 22:23 | <Philip`> | http://code.google.com/speed/webp/docs/c_study.html - ah, that has more data |
| 22:24 | <jacobolus> | yeah, their jpeg 2000 numbers seem pretty sketchy |
| 22:25 | <jacobolus> | is there any evidence that PSNR is a good metric for "human-detectable degradation" |
| 22:25 | <Philip`> | Seems the average improvement over (Re-)JPEG is more like 20% |
| 22:26 | <Philip`> | Are WebP and/or JPEG and/or JPEG2K optimised for PSNR? |
| 22:26 | <jacobolus> | I'd be very interested to see what the JPEG 2000 inventors have to say about this study |
| 22:26 | <jacobolus> | also, they took existing jpeg images to convert, it looks like? |
| 22:27 | <jacobolus> | of arbitrary provenance |
| 22:27 | <jacobolus> | some of those might be ickily compressed with lots of artifacts aligned with jpeg block boundaries |
| 22:35 | <Philip`> | http://code.google.com/speed/webp/index.html - "Did you know? WebP is pronounced "weppy"." - no it's not, it's pronounced "web pee" |
