| 00:34 | <annevk> | http://pipwerks.com/journal/2008/01/25/html-5-the-strong-element/ |
| 00:34 | <annevk> | SadEagle, thanks btw |
| 00:34 | <SadEagle> | np |
| 00:35 | SadEagle | thinks it'll be confusing for the default stylesheet |
| 00:35 | <annevk> | the default style sheet will be 'b, strong { font-weight:bolder }' presumably |
| 00:35 | <annevk> | or maybe for <b> it will just be 'b { font-weight:bold }' |
| 00:35 | <annevk> | hmm |
| 00:36 | <annevk> | it's not like browsers show much of a difference between the various font weights |
| 00:37 | <SadEagle> | Not too many fonts have natural variants for many weights --- or am I mistaken? |
| 00:38 | <annevk> | i guess that's the easy, yeah |
| 00:39 | <SadEagle> | this is kind of weird, since it seems like the styling one wants depends on appearance of the markup above, and not its element/etc. structure (or am I confusing myself?) |
| 00:40 | <annevk> | hmm, Safari doesn't support Link: <foobar.css>;rel=stylesheet |
| 00:41 | <annevk> | SadEagle, I'm not sure I understand what you're saying |
| 00:41 | <annevk> | as far as default styling goes, that's pretty much locked by legacy |
| 00:43 | <SadEagle> | annevk: I think I was being silly (I often am). the default styling of semantic elements isn't normally robust against changes to styling of surrounfing markup, right.. |
| 01:24 | <zcorpan_> | // ok we have a conforming XHTML1 doc in |doc| now. |
| 01:24 | <zcorpan_> | not true, the root element doesn't contain an xmlns declaration as the spec requires ;) |
| 01:25 | <zcorpan_> | (acid3) |
| 01:27 | jwalden | snickers |
| 01:27 | <SadEagle> | silly serializations and their xmlns attributes :-) |
| 01:28 | <jwalden> | silly DOM |
| 01:28 | <jwalden> | silly XML |
| 01:28 | <SadEagle> | DOM doesn't need xmlns's, though. |
| 01:28 | <zcorpan_> | silly xhtml spec that specifies document conformance in terms of the xml serialization |
| 01:29 | <SadEagle> | <chuckle> |
| 01:29 | <Philip`> | Is that an HTML-serialised chuckle, or are you just being ill formed? |
| 01:30 | <SadEagle> | no, that's IRC-serialization |
| 01:30 | <Philip`> | Hmm, that sounds highly unstandardised |
| 01:31 | <SadEagle> | thankfully, the typical parsers are highly robust |
| 01:32 | zcorpan_ | is still waiting for the end tag before rendering |
| 01:32 | <Philip`> | They have the advantage of being able to ask the author for clarification in case of unresolvable parsing ambiguities |
| 01:33 | zcorpan_ | doesn't support incremental content sink yet :( |
| 01:33 | <Ketsuban> | </chuckle> |
| 01:34 | <zcorpan_> | ah, thanks! |
| 01:34 | <SadEagle> | Philip`: the advantage is in a case? how odd |
| 01:41 | <othermaciej> | do xmlns attributes have to appear in the DOM? |
| 01:42 | <othermaciej> | (and do they affecte seriaization, if the element has the right namespace anyway?) |
| 01:42 | <zcorpan_> | othermaciej: not sure if they have to, but they do appear |
| 01:42 | <SadEagle> | I presume the second aprt would be DOM3 L&S, right? |
| 01:46 | <othermaciej> | DOM3 L&S is a pile of pernicious nonsense |
| 01:46 | <othermaciej> | but I guess something has to define it for specs like XHR and HTML5 to rely on |
| 01:47 | <SadEagle> | I guess for a usable serialization, it should produce xmlns attributes, but they can be local to each element that needs them... |
| 01:47 | <zcorpan_> | othermaciej: i guess declarations that are in conflict with the element's namespace or prefix is dropped or modified in the serialization, and unused declarations are serialized... well, assuming the serializer is sane |
| 01:47 | <SadEagle> | Ah prefixes... forgot that they're in the DOM. |
| 01:48 | <SadEagle> | So it's pretty easy to make a DOM that's not serializable to XML |
| 01:48 | <othermaciej> | zcorpan_: declarations could even be in conflict with children, if they were added through the DOM |
| 01:48 | <zcorpan_> | othermaciej: yeah, true |
| 01:48 | <othermaciej> | (I guess children could override them though |
| 01:48 | <othermaciej> | ) |
| 01:48 | <othermaciej> | so yeah, you can still do something sane an element at a time |
| 01:49 | <SadEagle> | attr's have their own namespace, don't they? |
| 01:49 | <zcorpan_> | yes |
| 01:49 | <zcorpan_> | namespace declarations have are in a special namespace |
| 01:49 | <othermaciej> | the meme that IE8 bugmode was developed "in collaboration with the Web Standards Project" has impressive traction |
| 01:49 | <othermaciej> | mentioned on ars technical with no disclaimer: http://arstechnica.com/articles/paedia/ie8-super-standards-mode.ars |
| 01:50 | <othermaciej> | ok I have a debate topic |
| 01:50 | <othermaciej> | XML Namespaces: Useless or Pointless? |
| 01:50 | <othermaciej> | discuss |
| 01:50 | <zcorpan_> | at least wrongly designed |
| 01:50 | <SadEagle> | zcorpan_: then one can probably use the same prefix with different namespaceURIs for an element and its attributes.. I don't think that's serializable |
| 01:50 | <SadEagle> | othermaciej: I like the idea, not the implementation |
| 01:51 | <othermaciej> | the concept of namespaces in general is good |
| 01:51 | <SadEagle> | CSS gets it better, IMHO |
| 01:51 | <othermaciej> | Namespaces in XML has some major problems |
| 01:51 | <zcorpan_> | SadEagle: serializable if you modify the prefixes |
| 01:51 | <othermaciej> | 1) the fact that namespace unique identifiers are URIs (and typically long, unmemorable http URIs) --> stupid |
| 01:52 | <othermaciej> | 2) the use of attribute syntax |
| 01:52 | <SadEagle> | re: #1: that's the easy way of managing a namespace. re: #2: that's why I think CSS gets it better :-) |
| 01:52 | <othermaciej> | 3) the two level thing with namespace URIs and prefixes, resulting in non-local prefix definitions |
| 01:53 | <othermaciej> | SadEagle: just DNS domain names would be better than URIs, if it is a critical goal not to add a registry |
| 01:53 | <othermaciej> | however, DNS is also a registry |
| 01:53 | <othermaciej> | if namespace identifiers were something that could be used as a prefix directly, it would suck a lot less |
| 01:53 | <SadEagle> | I guess one can shorten them w/o losing much. e.g. w3c.org/xhtml1 |
| 01:54 | <othermaciej> | if you could "import" namespaces like in C++ so long as they don't conflict, it would suck a lot less |
| 01:54 | <SadEagle> | that doesn't layer |
| 01:54 | <othermaciej> | "layer"? |
| 01:55 | <othermaciej> | I guess you'd still have to say something when creating elements |
| 01:55 | <SadEagle> | well, you can't make the parser resolve them. But that might not be such a big deal as on first sight |
| 01:55 | <othermaciej> | still, having only one kind of identifier which is always unique and if needed a registry for them would suck a lot less |
| 01:55 | <othermaciej> | but even org.w3c.xhtml (a la Java) would be way better than http://www.w3.org/1999/xhtm |
| 01:56 | <othermaciej> | (er, sorry, lost the l) |
| 01:56 | <zcorpan_> | a bit annoying if you want to use it as prefix for all elements though |
| 01:57 | <othermaciej> | this would also solve the problem that namespace-prefixed keywords in attribute values create |
| 01:57 | <SadEagle> | I'd personally have namespaceless attributes. |
| 01:57 | <SadEagle> | since their interpretation depends on the element, anyway. |
| 01:58 | <zcorpan_> | speaking of that |
| 01:58 | <SadEagle> | I guess it might help in cases like WF2, though. |
| 01:58 | <zcorpan_> | i think the xml: attributes suck |
| 01:58 | <othermaciej> | in theory namespaced attributes are intended to be element-independent |
| 01:58 | <othermaciej> | xml:id certainly sucks |
| 01:59 | <zcorpan_> | id='', class='' and lang='' and what other attribute i'm forgetting, if any, should have been superglobal attributes with predefined semantics in xml |
| 01:59 | <SadEagle> | othermaciej: as does the DOM3 idea of multiple id attributes.. |
| 01:59 | <othermaciej> | zcorpan_: that would have been better |
| 01:59 | <othermaciej> | zcorpan_: and xml:whitespace should have been omitted |
| 02:00 | <SadEagle> | ah, an another thing that sucks is the DOM special-casing of xml and xmlns attributes... |
| 02:00 | <othermaciej> | sorry, xml:space |
| 02:00 | <SadEagle> | it's specified to be completely oblivious to prefix and namespace binding -- except in one case... |
| 02:01 | <SadEagle> | xml:space --- is that the one that affects parsing? |
| 02:01 | <zcorpan_> | only if you're stipping whitespace |
| 02:02 | <zcorpan_> | with is a design problem in itself |
| 02:02 | SadEagle | looks it up... sounds... extraneous |
| 02:03 | <zcorpan_> | i mean the design problem is that whitespace in xml can either be content or pretty-print |
| 02:04 | <zcorpan_> | html has that too, though |
| 02:10 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cscript%3Edocument.createElement('header')%3C%2Fscript%3E%0D%0A%3Cbody%3E%3CHEADER%3Ea%3C%2Fheader%3Eb%3Cx%3Aheader%3Ec%3C%2FX%3AHEADER%3Ed |
| 02:12 | <zcorpan_> | oh, nm. i thought ie did something interesting there but it doesn't |
| 02:14 | <Dashiva> | Luckily ElementTraversal will save us from at least parts of the whitespace mess |
| 02:22 | <SadEagle> | from having to write loops? |
| 02:28 | <zcorpan_> | weird ie bug: <?xml-stylesheet type='text/css'?><x>&auml;</x> |
| 02:31 | <zcorpan_> | it can be carried further... |
| 02:31 | <zcorpan_> | y { color:red } |
| 02:32 | <zcorpan_> | <?xml-stylesheet type='text/css' href='test.css'?><x><y>TEST</x> |
| 02:38 | <zcorpan_> | or <?xml-...?><y><x> f<test>oo <z> b</test>ar </x> baz <z></y> |
| 02:42 | <zcorpan_> | acid2 breaks in almost standards mode |
| 02:43 | <othermaciej> | will IE8 have standards/almost standards versions of IE8 mode, I wonder? |
| 02:44 | <zcorpan_> | would make sense if they do what hsivonen proposed |
| 02:44 | <othermaciej> | obviously they won't |
| 02:44 | <SadEagle> | othermaciej: I think i get it now. Their stategy is to get all competing browser vendors to go nuts by trying to figure out what they're doing (oops, I think they might have tried it before) |
| 02:51 | <zcorpan_> | acid2 looks surprisingly similar in almost standards mode across fx, opera and safari. in fact i think they're actually pixel perfectly the same |
| 02:54 | <zcorpan_> | quirks mode is a bit different though, but fx and safari are pretty alike |
| 03:05 | <othermaciej> | I think Opera's quirks mode is somewhat more IE-like |
| 03:07 | <zcorpan_> | yeah |
| 03:09 | <othermaciej> | but yes, non-IE browsers are surprisingly similar even on things that aren't specifically standard |
| 03:09 | <othermaciej> | especially considering how vague many of the controlling standards are |
| 03:17 | <zcorpan_> | i should probably get along with writing my quirks spec so we can get a smiling acid quirks face cross-browser |
| 03:28 | <othermaciej> | IE changing their quirks mode seems pretty unlikely |
| 03:29 | <zcorpan_> | still, other browsers can interoperate |
| 03:31 | zcorpan_ | thinks quirks mode deserves more attention, given that it affects the vast majority of authors |
| 03:32 | <othermaciej> | it does |
| 03:32 | <othermaciej> | no question |
| 03:32 | <othermaciej> | interop is good |
| 03:32 | <othermaciej> | but caring about interop seems inversely proportional to market share, which is a little unfortunate |
| 03:32 | <SadEagle> | cutting down on reverse-engineering time is good, too |
| 03:33 | <othermaciej> | yes, good standards ensure long-term competitiveness in the face of new entrants |
| 03:33 | <othermaciej> | there hasn't been a serious new browser engine developed in some time |
| 03:34 | <othermaciej> | and many older ones have died out |
| 03:36 | <SadEagle> | well, what's the financial incentive, anyway? |
| 03:37 | <SadEagle> | there are good ones available under reasonable licensing terms for free, and I don't know about how much of differentiation one can get |
| 03:57 | <othermaciej> | true, doesn't seem like much incentive for a new one |
| 04:17 | <MikeSmith> | hsivonen, annevk (+whoever else might care) - deadline for submitting proposals for XTech has been extended to Monday |
| 04:17 | <MikeSmith> | http://2008.xtech.org/public/cfp/9 |
| 04:23 | <MikeSmith> | I'm writing a proposal for a presentation that looks at what substantial changes have been made to various browser engines over the last since (since XTech 2007 last May) |
| 05:18 | <zcorpan_> | "Style sheet data (%StyleSheet; in the DTD) can be the content of the STYLE element and the value of the style attribute. User agents must not evaluate style data as HTML markup." |
| 05:18 | <zcorpan_> | http://www.w3.org/TR/REC-html40/types.html#h-6.15 |
| 05:18 | <zcorpan_> | that means that entities and NCRs in style='' must not be resolved |
| 05:19 | <zcorpan_> | no? |
| 05:23 | <Ketsuban> | * zcorpan_ thinks quirks mode deserves more attention, given that it affects the vast majority of authors <- doesn't it defeat the object to create a standard for quirks mode? |
| 05:24 | <zcorpan_> | i don't follow |
| 05:45 | <Ketsuban> | zcorpan_: The whole point of quirks mode is that it's quirky - it doesn't follow any standards except the standards of the writer of the browser. |
| 05:46 | <othermaciej> | Ketsuban: the point of quirks mode is compatibility |
| 05:46 | <othermaciej> | (I'd call it "compatibility mode" if I were naming it) |
| 07:38 | <jruderman> | Hixie: are there specs that say whether https://bugzilla.mozilla.org/show_bug.cgi?id=340017 is a bug? |
| 07:39 | <othermaciej> | jruderman: no specs define the document.formName behavior |
| 07:40 | <jruderman> | ok |
| 07:40 | <jruderman> | i'd prefer for it to work in XHTML because i don't want there to be too many differences between HTML and XHTML |
| 07:44 | <jruderman> | https://bugzilla.mozilla.org/show_bug.cgi?id=371711 would be a fun one to have in acid3 |
| 07:47 | <jruderman> | https://bugzilla.mozilla.org/show_bug.cgi?id=378666 too |
| 07:51 | <othermaciej> | jruderman: putting things directly on window or document based on the markup is pretty dodgy because it creates namespace risk when those APIs are extended |
| 07:51 | <othermaciej> | jruderman: so I wouldn't feel too sad about XHTML phasing that practice out |
| 07:52 | <jruderman> | ok |
| 07:59 | <MacDomeOut> | ed_home: http://bugs.webkit.org/show_bug.cgi?id=16968 |
| 07:59 | <MacDome> | ed_home: Hixie used data: urls for load guarantees |
| 08:00 | <MacDome> | otherwise he'd have to use an additional <iframe> and re-write all his traversal tests to be aware of said iframe |
| 08:00 | <MacDome> | doing a dynamic insertion would not guarantee it to load fast enough |
| 08:07 | <jruderman> | https://bugzilla.mozilla.org/show_bug.cgi?id=393340 confuses me |
| 08:15 | <weinig> | MacDome: why would there need to be a guaranteed load speed? could the iframe simply call a function in it's parent to notify that it had finished loading? |
| 08:15 | <MacDome> | weinig: if the load is kicked off from teh test, part of Acid3 is that the anim shoudl be fluid |
| 08:15 | <MacDome> | so either the load needs to be done before any tests |
| 08:16 | <MacDome> | or the load needs to be basically instant |
| 08:16 | <MacDome> | weinig: I think Hixie had most recently decided to just add a "load up things" phase, which did all the loads (via js) after the onload, but before starting the tests |
| 08:16 | jwalden | sorta disagrees |
| 08:16 | <jwalden> | class += "P" |
| 08:17 | <jwalden> | as long as they happen, smoothness not so much a concern to me |
| 08:17 | <weinig> | MacDome: is there any spec that states that data: urls are loaded synchronously? |
| 08:17 | <MacDome> | weinig: no, that part has nothing to do with data loads |
| 08:17 | <weinig> | MacDome: nm |
| 08:17 | <jwalden> | does *any* URL load sync? |
| 08:17 | <MacDome> | it has to do with not being able to use external loads |
| 08:17 | <jwalden> | I'm not aware of anything |
| 08:17 | <weinig> | that was a dumb question |
| 08:18 | <MacDome> | src="foo.svg" |
| 08:18 | <MacDome> | load speed should not affect animation speed |
| 08:18 | <MacDome> | at least resource fetch speed shouldn't |
| 08:18 | <MacDome> | that's not the point of the test |
| 08:19 | <MacDome> | so he needs to preload them, or use data urls |
| 08:19 | <MacDome> | he didn't want to edit the actual source (since that would change the traversed dom) |
| 08:19 | <MacDome> | so he needs to add a pre-load phase |
| 08:19 | <MacDome> | a "load up everything before actually kicking off the tests" phase |
| 08:24 | <hsivonen> | jwalden: re: constant-time indexing and UTF-32, roc has a good blog post about why string indexing misses the point |
| 08:24 | <jwalden> | that it does isn't the point |
| 08:24 | <jwalden> | er |
| 08:25 | <jwalden> | I think it's a reasonable tradeoff in the long haul |
| 08:25 | <jwalden> | memory is cheap |
| 08:25 | <jwalden> | and getting cheaper |
| 08:26 | <roc> | gah |
| 08:27 | <jwalden> | although |
| 08:28 | <jwalden> | it makes more sense as an internal format than as something you'd send over the network |
| 08:28 | <roc> | memory may be cheap but memory bandwidth, cache and CPU arne't |
| 08:29 | <jwalden> | sure |
| 08:29 | <roc> | and maybe we should use memory for useful stuff instead of just wasting up |
| 08:29 | <roc> | then there's mobile |
| 08:29 | <jwalden> | for some work loads that may not matter |
| 08:29 | <hsivonen> | jwalden: in any case, sending UTF-32 over the network makes absolutely no sense |
| 08:29 | <hsivonen> | jwalden: only test suites do it |
| 08:30 | <hsivonen> | jwalden: and if browsers support it and sites other than test suites use it for whatever misguided reason, non-browser scrapers need to add UTF-32 |
| 08:31 | <hsivonen> | and if the UTF-32 decoder doesn't exist as part of the platform, implementing it is a remarkable bad use of developer time |
| 08:32 | <hsivonen> | jwalden: IIRC, the UTF-32 should not was put in the spec after Mike Day pointed out that implementing UTF-32 support in Prince would have been useless use of dev time |
| 08:34 | <hsivonen> | UTF-32 has already wasted my time since the JDK doesn't support it but ICU4J does and I want the V.nu parser to be usable on pure JDK but also use ICU4J when available |
| 10:57 | <hsivonen> | http://en.wikipedia.org/wiki/HTML#Elements |
| 10:57 | <hsivonen> | "label" hmmkay |
| 12:20 | <ed_japan> | MacDomeSleep: dataURI:s may load faster but I don't know if that's guaranteed, I think having them like that is fine but it's probably better to preload the necessary resources before starting the test |
| 12:20 | <MacDomeSleep> | ed_home: I expet that's what Hixie is planning on doing |
| 12:20 | <MacDomeSleep> | ed_home: the data: load is expected to be synchronous I bet |
| 12:24 | <annevk> | it's not |
| 12:24 | <annevk> | it's just expected to take very little time |
| 13:01 | <gsnedders> | hsivonen: for the validator, how do you know whether to use ISO-8859-1 or Windows-1252? |
| 13:03 | <annevk> | isn't ISO-8859-1 just an alias? |
| 13:05 | <gsnedders> | he lists both in the options |
| 13:05 | <gsnedders> | is ISO-8859-1 only ever sniffed as Windows-1252 so to validate using ISO-8859-1 you need to explicitly use it? |
| 13:24 | <hsivonen> | gsnedders: the override overrides the HTTP layer encoding info |
| 13:24 | <hsivonen> | gsnedders: the result follow from that |
| 13:25 | <hsivonen> | gsnedders: so it is an alias in the HTML case but different encoding in the XML case |
| 13:25 | <gsnedders> | ah. |
| 13:25 | <hsivonen> | I could be persuaded to take ISO-8859-1 off the menu |
| 13:27 | <gsnedders> | I found some many mis-served feeds that I treat ISO-8859-1 as Windows-1252 in XML too, FWIW |
| 13:42 | <annevk> | making ISO-8859-1 an alias for Windows-1252 "globally" seems like the most practical solution |
| 13:43 | <gsnedders> | anyone want to try and register that? :P |
| 13:44 | <Philip`> | Surely ISO wouldn't mind updating their spec to better match reality |
| 13:45 | gsnedders | dunnos |
| 13:46 | <hsivonen> | from the usability point of view, though, should I keep the menu item? |
| 13:46 | <hsivonen> | browsers keep the menu item |
| 13:47 | <hsivonen> | but a validator is aimed at a different audience |
| 13:50 | <gsnedders> | Philip`: Hmm, I doubt we could get ISO-8859-1 changed. We have more hope at getting the IANA to register it as an alias. |
| 13:51 | <hsivonen> | gsnedders: I don't think the IANA subscribes to WHATWG principles yet |
| 13:51 | <gsnedders> | Nor do I. |
| 13:51 | <gsnedders> | All I said is "more hope", not having much :) |
| 14:03 | <annevk> | maybe we should have an alternative to IANA on the WHATWG wiki (A) |
| 14:03 | <gsnedders> | :D |
| 15:04 | <hsivonen> | hmm. Looks like Shelley Powers went application/xhtml+xml-only even for IE |
| 15:05 | <hsivonen> | I wonder if others who write reading-worthy stuff follow her lead |
| 15:05 | <annevk> | maybe I should start serving up style sheets using Link: |
| 15:06 | <hsivonen> | annevk: that's a bit different, though |
| 15:06 | <hsivonen> | Link was removed from HTTP 1.1 |
| 15:07 | <webben_> | hsivonen: hmm, when I curl http://burningbird.net/ I get text/html. |
| 15:07 | <webben_> | "XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN" served as text/html to be precised |
| 15:07 | <webben_> | *precise |
| 15:07 | <hsivonen> | webben_: ah. I only tried realtech.burningbird.net (checked with IE UA string and Accept: text/html) |
| 15:51 | <zcorpan_> | this is probably the sneakiets spam i've ever seen... http://forums.whatwg.org/viewtopic.php?t=134 |
| 15:51 | <zcorpan_> | well, at least on f.w.o |
| 15:53 | <zcorpan_> | "Hello! |
| 15:53 | <zcorpan_> | Could you tell me a portal where I can add advertisements for printing and graphic art machines free? |
| 15:53 | <zcorpan_> | Here’s one www.allf...." |
| 16:15 | <zcorpan_> | hsivonen: i fixed the terminology on the wikie page. well, only in that section. we'll see if someone reverts it or fixes the rest |
| 16:15 | <zcorpan_> | s/wikie/wiki/ |
| 16:16 | <hsivonen> | zcorpan_: thanks |
| 16:17 | <hsivonen> | earlier today, I added mentions of the HTML5 WD to wikipedia |
| 16:17 | <hsivonen> | I'm slightly surprised that the hive mind hadn't taken care of it |
| 16:18 | <hsivonen> | or it had for "HTML 5" but not for "HTML" and "XHTML" |
| 16:43 | <hsivonen> | I could waste the whole weekend if I wanted to fix what the Finnish Wikipedia says about HTML matters |
| 16:43 | <hsivonen> | :-( |
| 16:44 | <annevk> | give it a few years |
| 16:44 | <annevk> | there's no hurry |
| 16:53 | <hsivonen> | the quality of Web-related articles on the Finnish wikipedia is really sad |
| 16:54 | <hsivonen> | I guess the people who care are literate in English and prefer to play in the bigger sandbox |
| 16:54 | <hsivonen> | like me |
| 16:54 | <annevk> | whoa |
| 16:55 | <annevk> | i just noticed that the guy who asked about extensibility is from microsoft |
| 16:56 | <annevk> | it does say so pretty clearly at the bottom of http://lists.w3.org/Archives/Public/public-html-comments/2008Jan/0038.html but then I don't read very well :o |
| 16:56 | <annevk> | i guess my answer would still have been pretty much the same |
| 16:57 | <hsivonen> | annevk: I think your answer missed the point |
| 16:58 | <hsivonen> | annevk: the way I read it was that (s)he wanted to add custom elements to bind the XBL stuff to |
| 16:58 | <annevk> | from http://www.nikhilk.net/HTML5-Thoughts.aspx I gathered that it was also about XBL |
| 16:58 | <annevk> | or HTC |
| 16:59 | <annevk> | " I would have loved to see the HTML 5 spec address extensibility of the tag set and rationalize things like HTC behaviors and XBL bindings." |
| 16:59 | <annevk> | though maybe I misunderstand "rationalize" |
| 17:00 | <hsivonen> | I think it means that XBL is kind of pointless as an implementation mechanism for custom elements if HTML5 doesn't allow you to create custom elements |
| 17:00 | <annevk> | ah ok |
| 17:01 | <annevk> | he has some thoughts on <dialog> too: http://www.nikhilk.net/HTML5-Dialog-Microformats.aspx |
| 17:01 | SadEagle | reads the charset thread and wonders whether some people would have a different opinion if they were not from Western Europe |
| 17:03 | <hsivonen> | SadEagle: UTF-8 covers all of Unicode and Western Europe has a legacy to get rid of, too |
| 17:06 | <SadEagle> | hsivonen: sure. But e.g. I can tell you that for Cyrillic (at least Russian), it used to be a real mess (and still parly is) --- some of the bigger websites would have proxies to automatically recode things into different encoding, including transliteration into latin.. |
| 17:06 | <hsivonen> | SadEagle: I know. Are we talking about the same thread? |
| 17:06 | <SadEagle> | hsivonen: probably.... ... and despite having 2+ codes in wide uses, a lot of websites would not specify their encoding, so good encoding autoguessing is actually a part of interoperability needs :( |
| 17:08 | <hsivonen> | SadEagle: yeah, failure to declare the encoding is a very, very bad idea. |
| 17:08 | <hsivonen> | I was referring to the public-html-comments thread. |
| 17:09 | <SadEagle> | yeah, me too. BTW, on the link to verifier you added... apparently some people actually use MacCyrrilic. Not too many, thankfully. |
| 17:10 | <SadEagle> | (I don't think i've seen anyone use 8859-5, though) |
| 17:12 | <hsivonen> | SadEagle: apparantly no one has cared enough to register MacCyrillic with the IANA, so it's not on the list |
| 17:12 | <hsivonen> | and, yes, the Web might not break if ISO-8859-5 were not supported |
| 17:12 | <hsivonen> | but then, it is supported and registered, so it is on my list |
| 17:14 | <hsivonen> | SadEagle: btw, that list is the intersection of the IANA registry, Python 2.4 (or 2.3 I forget), Sun JDK 1.4.2, IE 7, Firefox 2, Safari 2 and Opera 9 |
| 17:14 | <hsivonen> | minus US-ASCII which doesn't make sense as an override |
| 17:15 | <SadEagle> | sounds reasonable, expect you probably have to union in IE6 :( |
| 17:16 | <hsivonen> | if that add encodings, they are probably seriously in the diminishing returns department and cover very little Web content |
| 17:16 | <hsivonen> | s/add/adds/ |
| 17:18 | <hsivonen> | in any case, my point is that the proliferation is bad and BOCU-1 is not part of the real Web content legacy |
| 17:19 | <SadEagle> | I guess my point is that you won't have to explain that to people who had to deal with a whole bunch of encoding legacy :-) |
| 18:36 | <hsivonen> | the WHATWG wiki doesn't have Atom feeds like wikipedia |
| 18:36 | <hsivonen> | can I get email notifications from the WHATWG wiki when it is edited? |
| 18:37 | <hsivonen> | hmm. looks like I already have that enabled. the wiki just isn't edited often |
| 18:46 | <marcreichelt> | hi there :) |
| 18:46 | <marcreichelt> | I have a question about HTML 5 |
| 18:47 | <marcreichelt> | is there a rational reason for the <embed> element being part of the new HTML 5 draft? |
| 18:48 | <marcreichelt> | because then there would be 2 elements for embedding random content - <embed> and <object> |
| 18:49 | <SadEagle> | that's the least of problems with embed :-) |
| 18:50 | <annevk> | <object> is a generic inclusion mechanism, <embed> is for plugins |
| 18:50 | <annevk> | so <embed> is actually a specific form of <object>, just like <img> |
| 18:51 | <hsivonen> | marcreichelt: content authors need embed to support existing browsers, so we might as well make it valid |
| 18:51 | <marcreichelt> | which browser needs embed today? |
| 18:51 | <SadEagle> | all of them |
| 18:51 | <marcreichelt> | besides, Netscape is dead |
| 18:51 | <SadEagle> | if you mean from the browser side, not author side |
| 18:51 | <annevk> | yes, but <embed> isn't :) |
| 18:51 | <marcreichelt> | and all the multimedia content can be embedded via object, too |
| 18:52 | <SadEagle> | annevk: <lazy>does html5 still do the evil embed-in-object thing though</lazy> ? |
| 18:52 | <marcreichelt> | :( |
| 18:52 | <annevk> | SadEagle, <object> can have <embed>, sure |
| 18:53 | <hsivonen> | embed in object is still needed to make Flash work in both IE and Firefox |
| 18:53 | <marcreichelt> | no |
| 18:53 | <marcreichelt> | it is not |
| 18:53 | <SadEagle> | annevk: but is there any special behavior outside of normall fallback content there? |
| 18:53 | <hsivonen> | marcreichelt: can you get one object to work in both with accessibility stuff and all? |
| 18:54 | <marcreichelt> | oh - I think I know what you are talking about |
| 18:54 | <marcreichelt> | so you are taking <embed> in because of the accessibility? |
| 18:55 | <marcreichelt> | if HTML 5 wouldn't have <embed> in it, the creators of accessibility programs (like YAWS) will definitely fix this |
| 18:56 | <hsivonen> | marcreichelt: I can't say what rationale Hixie had, but from my point of view, admitting that it exists and making it conforming is more productive than embarking on a massive re-education campaign |
| 18:56 | <marcreichelt> | the support of two elements (object AND embed) is just not reasonable to me |
| 18:56 | <marcreichelt> | :( |
| 18:56 | <hsivonen> | marcreichelt: browsers other than IE will have to support both no matter what the spec says |
| 18:56 | <hsivonen> | marcreichelt: it is mainly an issue of whether we admit <embed> as conforming |
| 18:57 | <marcreichelt> | "browsers other than IE" |
| 18:57 | <marcreichelt> | ? |
| 18:58 | <hsivonen> | marcreichelt: evidence shows MS can get away with doing something different |
| 18:58 | <marcreichelt> | my argument is: if you will conform the embed-Element, the evil embed-in-object thing will live long and prosper |
| 18:58 | <hsivonen> | what's evil about it? |
| 18:59 | <marcreichelt> | you have to embed the same content twice |
| 18:59 | <marcreichelt> | and the parameters of embed and object have to be kept twice |
| 19:00 | <marcreichelt> | this is a great source for errors (why does IE play my flash movie, but Firefox does not?) |
| 19:01 | <SadEagle> | marcreichelt: actually, you only need most stuff on the embed |
| 19:01 | <SadEagle> | object will automatically pick stuff up from it. |
| 19:02 | <marcreichelt> | right now, special parameters for embed are passed by non-conform attributes |
| 19:02 | <marcreichelt> | for object, there is the <param>-Tag |
| 19:05 | <hsivonen> | marcreichelt: it is kind of pointless to change HTML5 if https://bugzilla.mozilla.org/show_bug.cgi?id=46569 doesn't get reversed and the current installed based replaced |
| 19:06 | <hsivonen> | marcreichelt: HTML5 makes the embed attributes conforming, so they're no longer non-conform :-) |
| 19:06 | <marcreichelt> | hsivonen: and what about the parameters for the content? |
| 19:07 | <hsivonen> | marcreichelt: they are conforming, too, per HTML5 |
| 19:07 | <marcreichelt> | just look at the standard-embed for any multimedia (Flash or something like that) content |
| 19:07 | <marcreichelt> | for example flash: |
| 19:07 | <marcreichelt> | http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_4150&sliceId=2 |
| 19:07 | <marcreichelt> | <embed> is not like <embed src="..." type="..." width="..." height="..." /> |
| 19:07 | <marcreichelt> | but like: |
| 19:08 | <marcreichelt> | <embed src="..." type="..." width="..." height="..." bgcolor="..." pluginspage="..." quality="..." fooattribute="..." /> |
| 19:08 | <hsivonen> | marcreichelt: the errors I got from Validator.nu pertain to classid, codebase and the end tag </embed> |
| 19:09 | <hsivonen> | marcreichelt: the spec allows that stuff |
| 19:09 | <marcreichelt> | wohw? |
| 19:09 | <marcreichelt> | no :( |
| 19:09 | <marcreichelt> | ok, thats it |
| 19:09 | <marcreichelt> | HTML 5 is no goot to me |
| 19:09 | <marcreichelt> | -t+d |
| 19:09 | <SadEagle> | marcreichelt: the point is interoperability. |
| 19:10 | <marcreichelt> | so I believe <embed> can take _any_ attribute? |
| 19:10 | <hsivonen> | marcreichelt: yes |
| 19:10 | <marcreichelt> | wahh |
| 19:10 | <marcreichelt> | ok |
| 19:10 | <SadEagle> | people don't write nice mark up. This sort of thing is one the web, and it'll be on the web regardless of what html5 says |
| 19:10 | <marcreichelt> | great |
| 19:10 | <hsivonen> | marcreichelt: or, rather, any attribute that is not in a namespace |
| 19:10 | <marcreichelt> | is this allowed for other elements, too? |
| 19:10 | <hsivonen> | marcreichelt: no |
| 19:10 | <marcreichelt> | kay |
| 19:11 | <hsivonen> | marcreichelt: the W3C tried to kill <embed> a decade ago |
| 19:11 | <hsivonen> | marcreichelt: <embed> is still around so we might as well admit that killing it didn't work |
| 19:12 | <marcreichelt> | or maybe there has not been enough time |
| 19:12 | <hsivonen> | marcreichelt: is getting rid of <embed> really worth a more than a decade of trying? |
| 19:12 | <marcreichelt> | yes |
| 19:12 | <SadEagle> | it won't happen. |
| 19:13 | <marcreichelt> | it is worth to me if I see complex constructions like the embed-in-object |
| 19:13 | <marcreichelt> | and users that are confused why they have to type in the same information twice |
| 19:13 | <SadEagle> | marcreichelt: it's even uglier on the implementation end, but the implementors will have to support it /anyway/. So it's better to bring some order to it. |
| 19:14 | <marcreichelt> | if you say so |
| 19:14 | <marcreichelt> | you are the master |
| 19:14 | <marcreichelt> | ;) |
| 19:14 | <SadEagle> | I am not :-). Well, I sort of am on the "ugly on the implementation end" part.. |
| 19:15 | <marcreichelt> | k |
| 19:15 | <marcreichelt> | for which implementation if I may ask? |
| 19:16 | <SadEagle> | khtml. |
| 19:16 | <marcreichelt> | ah, okay :) |
| 19:17 | <SadEagle> | I think it can be simplified by taking advantage of fallback content, though |
| 19:17 | <marcreichelt> | all I can say is that having the embed element is not good for a longer time |
| 19:17 | <hsivonen> | marcreichelt: Flash itself is a much bigger problem than the entry point |
| 19:17 | <marcreichelt> | and there is no alternative content for <embed>, right? |
| 19:17 | <gsnedders> | right. |
| 19:18 | <hsivonen> | marcreichelt: the main use case for <embed> is Flash and the right way to do Flash accessibility is to have the Flash player talk to the accessibility framework |
| 19:19 | <marcreichelt> | so the alternative content of the <object> element will always be an <embed> element |
| 19:19 | <hsivonen> | pretty much, yes. |
| 19:20 | <marcreichelt> | so in the case no Flash Player is installed there will be no alternative content |
| 19:21 | <hsivonen> | marcreichelt: right |
| 19:21 | <SadEagle> | marcreichelt: and actually, part of the problem for a minor developer is that one has to reverse-engineer this sort of stuff... So having it written down helps |
| 19:21 | <hsivonen> | marcreichelt: evidence suggests that authors either don't care or provide an <a href link to alternative content |
| 19:22 | <marcreichelt> | why don't they care? |
| 19:22 | <marcreichelt> | because it is not possible right now |
| 19:22 | <hsivonen> | marcreichelt: and Flash being proprietary is the real problem behind Flash not being installed somewhere |
| 19:22 | <marcreichelt> | because the alternative content for an object element will be an embed element |
| 19:23 | <SadEagle> | marcreichelt: is impossibility why many websites don't have "well-structured" markup? |
| 19:23 | <hsivonen> | marcreichelt: ad hoc analysis suggests that Flash is often used for marketing and if marketers care about alternative content, they think of SEO first |
| 19:24 | <hsivonen> | marcreichelt: marketers usually don't care about FreeBSD on MIPS or other platforms that don't run Flash |
| 19:25 | <hsivonen> | marcreichelt: and like I said, alternative content isn't the right way to do Flash accessibility |
| 19:25 | <marcreichelt> | no - not do do Flash accessibility |
| 19:25 | <gsnedders> | hsivonen: heck, they don't care about Windows x64, yet alone FreeBSD on MIPS |
| 19:25 | <hsivonen> | gsnedders: good point |
| 19:27 | <marcreichelt> | okay then |
| 19:27 | <hsivonen> | basically, to do what's done with Flash but in a non-proprietary way, there are <canvas>, <video> and <svg> |
| 19:27 | <marcreichelt> | I think there is no possibility to change this |
| 19:36 | <marcreichelt> | see you |
| 19:38 | <harri> | annevk: you had been writing some xmlhttprequest tests, right? |
| 19:43 | <hsivonen> | is there a pure python alternative for pygenx? does html5lib contain one by any chance? |
| 19:59 | <hsivonen> | hmm. interesting. iCab 4 contains only the Growl framework, which suggests all the features have been implemented with the OS copy of WebKit |
| 21:06 | gsnedders | realises he's reading the GZIP spec wrong |
| 21:07 | <gsnedders> | the bits are written in big-endian form within a byte, with bytes in little-endian order |
| 21:10 | <kig> | is there even a system that uses little-endian bit order within byte.. |
| 21:11 | <roc> | that never matters |
| 21:11 | <roc> | oh I guess it does for gzip |
| 21:13 | <gsnedders> | it doesn't, AFAIK |
| 21:19 | <gsnedders> | gzip is defined as a sequence of 8-bit bytes, with certain parts being little-endian words |
| 21:20 | <gsnedders> | How you choose to store those bits is up to you. |
| 21:45 | <zcorpan_> | hsivonen: "In that case, you a probably better off tracking XHTML5 as opposed to XHTML 1.1." -- s/a /are / |
| 21:51 | <annevk> | harri, http://tc.labs.opera.com/apis/XMLHttpRequest/ |
| 21:52 | <SadEagle> | annevk: I am quite impressive by how you folks don't block the UI on synchronous (puke) XHR |
| 21:52 | <SadEagle> | impressed, that is. |
| 21:54 | <hsivonen> | zcorpan_: thanks. fixed |
| 21:55 | <jwalden> | synchronous APIs are bad |
| 21:55 | <jwalden> | albeit convenient |
| 21:55 | <jwalden> | just gotta bite the bullet |
| 21:57 | <gsnedders> | ABNF isn't expressive enough. |
| 21:59 | <annevk> | SadEagle, that's probably one of my favorite Opera features |
| 22:00 | <gsnedders> | RFC 1952 is too vague. |
| 22:03 | <hsivonen> | annevk: does Presto run in the UI thread nonetheless? |
| 22:03 | <SadEagle> | hmm, looks like we need lots of work on that tc.. |
| 22:04 | <annevk> | I'd recommend coding against http://dev.w3.org/2006/webapi/XMLHttpRequest/ and then use the tests to verify |
| 22:04 | <annevk> | so we can catch bugs in both |
| 22:04 | <annevk> | (well, and in your impl :) ) |
| 22:04 | <SadEagle> | Well, the code is there, but it could surely use an audit. |
| 22:04 | <SadEagle> | how interoperable is the stuff the tests test? |
| 22:04 | <annevk> | hsivonen, can't comment on that I think |
| 22:05 | <hsivonen> | annevk: ok |
| 22:05 | <annevk> | SadEagle, it's compatible with other browsers |
| 22:05 | <annevk> | I think we aligned with IE the most |
| 22:12 | <annevk> | acid test moved: http://acid3.acidtests.org/ |
| 22:14 | <hsivonen> | Hixie: acid3 just crashed my copy of firefox 2 |
| 22:20 | <annevk> | so is text/html;charset=latin1 identical to text/html;charset=iso-8859-1 ? |
| 22:22 | <hsivonen> | annevk: if you use an alias, v.nu will tell you the preferred iana name |
| 22:22 | <annevk> | but aliases are supported and such? |
| 22:23 | <hsivonen> | yes |
| 22:23 | <hsivonen> | http://validator.nu/?doc=http%3A%2F%2Fw3.org%2F&charset=latin1 |
| 22:23 | <hsivonen> | yes, latin1 is an alias of iso-8859-1 |
| 22:24 | <hsivonen> | oh, did you mean supported in browsers? I'm not sure |
| 22:24 | <annevk> | regarding that document, the lang= attribute value message is confusing |
| 22:24 | <annevk> | yeah, i'd guess so... |
| 22:25 | <annevk> | would be nice if documentation on this sucked less |
| 22:26 | <annevk> | and also exact algorithms for bytestream + encoding -> unicode character stream |
| 22:26 | <hsivonen> | which message is confusing? |
| 22:26 | <annevk> | including handling errors, etc. |
| 22:26 | <annevk> | " Attribute lang not allowed on XHTML element html at this point." |
| 22:26 | <annevk> | where you mean xml:lang probably |
| 22:27 | <annevk> | oh wait |
| 22:27 | <hsivonen> | annevk: no, lang is not allowed |
| 22:27 | <hsivonen> | xml:lang is allowed |
| 22:27 | <annevk> | it's served as XML, blah |
| 22:27 | <hsivonen> | hmm. the page has hreflang='en-uk' even |
| 22:28 | <annevk> | i think lang= should be allowed, but i don't care enough to raise it |
| 22:30 | <annevk> | "XML processors are required to support the UTF-8 and UTF-16 character encodings. The encoding was latin1 instead, which is an incompatibility risk." |
| 22:30 | <annevk> | wasn't that supposedly disabled for ISO-8859-1? |
| 22:32 | <hsivonen> | annevk: yeah, but apparently, the code compares the declared charset--not the canonical name |
| 22:33 | <hsivonen> | which is OK, considering that aliases may not be as safe as "ISO-8859-1" |
| 22:34 | <hsivonen> | compare with http://validator.nu/?doc=http%3A%2F%2Fw3.org%2F&charset=iso-8859-1 |
| 22:41 | <annevk> | k |
| 23:13 | <zcorpan_> | Hixie: s#</#</#g in html5 source |
| 23:13 | <zcorpan_> | (validating the spec now worked, but it took a while) |