| 00:07 | <Hixie> | so i'm thinking of making the parser introduce xml:base attributes as the way to handle stray <base> elements |
| 00:07 | <Hixie> | anyone see anything wrong with that? |
| 00:08 | <Hixie> | the alternatives are to have a magical base resolution mechanism and simply ignoring stray <base> tags |
| 00:08 | <zcorpan_> | ie7 ignores stray <base>s, doesn't it? |
| 00:08 | <zcorpan_> | (or is that in standards mode only?) |
| 00:08 | <Hixie> | probably both |
| 00:09 | <Hixie> | as in, "yes" to both questions, probably |
| 00:09 | <zcorpan_> | right. and we want to deal with quirks :) |
| 00:09 | <zcorpan_> | (at least if the web relies on them) |
| 00:09 | <Hixie> | i wonder if i have some data on <base> elements |
| 00:10 | <zcorpan_> | it amused me when ms decided to ignore stray <base>s... obviously they based their implementation on document conformance requirements in html4 |
| 00:11 | <Hixie> | about 5% of sites have 1 <base> tag, apparently |
| 00:12 | <Hixie> | 0.03% have 2 |
| 00:12 | bewest | uses base |
| 00:12 | <Hixie> | 0.0017% have 3 |
| 00:12 | <zcorpan_> | but does defining it with xml:base work? i mean if there are multiple <base>s in the same parent |
| 00:12 | <Hixie> | and a few thousand have more than 3 |
| 00:13 | <Hixie> | zcorpan_: i would make the xml:base be set on every element until the next <base>, i guess |
| 00:13 | <zcorpan_> | ah. right |
| 00:14 | <Hixie> | so we're talking about a few million pages here |
| 00:14 | <Hixie> | with 2 or more <base> elements |
| 00:14 | <Hixie> | i wonder how many have the same URI in both <base> elements |
| 00:14 | <zcorpan_> | there might be pages that use only one but have it in the middle |
| 00:15 | <zcorpan_> | <link href><base href><link href> |
| 00:15 | <Hixie> | oh actually this was only counting _different_ values for <base> |
| 00:15 | <Hixie> | so a few million pages use two different values for <base> |
| 00:18 | <zcorpan_> | so if you serialize to xml, do you drop the <base>s? |
| 00:19 | <zcorpan_> | afaict browsers don't ignore <base> in xhtml |
| 00:20 | <zcorpan_> | for some reason i think magical base resolution mechanism would work better |
| 00:22 | <zcorpan_> | i'm not an implementor though but i'm just observing what browsers are doing today :) |
| 00:25 | <Hixie> | yeah, dunno |
| 00:25 | Hixie | needs to study this more |
| 00:26 | <Hixie> | my main concern with supporting <base> in XHTML is that it means URI resolution will be different in XHTML UAs than pure XML UAs |
| 00:26 | <Hixie> | but i guess i can point the topic at myself |
| 00:27 | <zcorpan_> | ah. so you'd like to drop support for <base> in xhtml5 completely? |
| 00:27 | <Hixie> | that's what the spec says today iirc |
| 00:27 | <Hixie> | but people have argued against that |
| 00:28 | <bewest> | I like base |
| 00:28 | <bewest> | it makes it easy to develop entire websites and then move the whole thing |
| 00:28 | <bewest> | only thing you need to change is a variable somewhere |
| 00:28 | <Hixie> | you like <base>, or you like the concept of having a base URI? |
| 00:28 | <bewest> | base URI |
| 00:28 | <zcorpan_> | it says authors must not use it in xml. afaict it doesn't say uas must ignore it in xml |
| 00:28 | <Hixie> | ok well that's fine, nobody's talking about removing that feature :-) |
| 00:29 | <bewest> | ah |
| 00:29 | <Hixie> | we're just talking about the syltax |
| 00:29 | bewest | pipes down |
| 00:29 | <Hixie> | zcorpan_: ah |
| 00:29 | <Hixie> | hehe |
| 00:30 | <zcorpan_> | today, browsers don't ignore <base> in xml, but since 0.00% of the web use xml it might not be much of an issue to change that :) |
| 00:31 | <Hixie> | :-) |
| 00:31 | <Hixie> | yeah, especially since 95% of pages don't use base stuff at all |
| 00:31 | <Hixie> | so that'd make it 5% of 0.00% :-) |
| 00:31 | <zcorpan_> | indeed :) |
| 00:33 | <Philip`> | I guess a physicist would call that 0.000% |
| 00:34 | <zcorpan_> | but <base href> changes the #document base uri. xml:base at best changes the root element's base uri |
| 00:34 | <zcorpan_> | (which makes a difference with xhr iirc) |
| 00:34 | <Hixie> | yeah |
| 00:36 | <Hixie> | talking about t-shirts |
| 00:36 | <Hixie> | here's one |
| 00:36 | <Hixie> | it just says "XForms is the automobile." on it |
| 00:36 | <othermaciej> | lol |
| 00:36 | <Dashiva> | I thought xforms was the lightbulb |
| 00:37 | <othermaciej> | and HTML forms is LOAD AX, 1000 |
| 00:37 | <othermaciej> | but we really need more declarative syntax for that |
| 00:38 | <Dashiva> | op="load" ra="ax" rb="1000" ? |
| 00:38 | <zcorpan_> | we need spreadsheets to make our t-shirts |
| 00:38 | <othermaciej> | it really should be <instruction><opcode>LOAD</opcode><operand type="register">AX</operand><operand type="integer-constant">1000</operand></instruction> |
| 00:39 | <othermaciej> | then you can abstract opcode to be a processor-independent operation, and use psuedo-registers for your registers, and allow the author to add a declarative model of their instruction set and pipeline model |
| 00:39 | <Hixie> | don't forget version="1.0" on the <instruction> element |
| 00:39 | <othermaciej> | and optimal code can be generated automatically |
| 00:40 | <Philip`> | You could do all your register allocation using XSLT |
| 00:40 | <zcorpan_> | most importantly, it can be produced by authoring tools for people who don't know about markup |
| 00:41 | <Dashiva> | They don't even need to know assembly if we abstract away the commands well enough |
| 00:47 | <bewest> | yes, we should have declaritive expressions for spreadsheets for people who can't author them, but we should also be sure to leave <font> out of it |
| 00:47 | <bewest> | 'cause <font> is what those browser-makers want |
| 00:47 | <othermaciej> | bewest: to be fair, that's two separate groups of crazy people |
| 00:47 | <bewest> | yeah |
| 00:47 | <bewest> | but it's all crazy if you ask me |
| 00:49 | <othermaciej> | I'm just waiting for the "remove all vestiges of presentational markup" people to get in a fight with the "we need more presentational markup" people |
| 00:49 | <othermaciej> | someone should Cc Tina on the <indent> thread |
| 00:50 | <Dashiva> | That would probably make the server kneel under the load |
| 02:07 | <Hixie> | so... |
| 02:08 | <Hixie> | IE only handles <base href=""> on the first <base> element |
| 02:08 | <Hixie> | but |
| 02:08 | <Hixie> | it handles <base target> the same way as before |
| 02:09 | <othermaciej> | that's kinda freaky |
| 02:14 | <Hixie> | so does safari have any bugs about compat regarding your <base target> handling? |
| 02:15 | <othermaciej> | I'll see if I can find any |
| 02:15 | <othermaciej> | but it's unlikely I can give a definitive "no" |
| 02:16 | <othermaciej> | since there could well be unreduced bugs that boil down to that issue |
| 02:19 | <othermaciej> | I have one titled "Documents with multiple base tags handled differently than IE" |
| 02:19 | <othermaciej> | but it does not appear to involve target |
| 02:19 | <othermaciej> | and may be obsoleted by IE7 |
| 02:20 | <Hixie> | k |
| 02:22 | <othermaciej> | Hixie: I couldn't find any that were clearly about <base target>, but I only found very few that were about <base> at all (4 total) |
| 02:22 | <othermaciej> | there could easily be more lurking in unreduced bugs |
| 02:22 | <Hixie> | k |
| 02:22 | <Hixie> | thanks |
| 02:22 | <Hixie> | do let me know if you spot anything in future |
| 02:30 | <tantek> | is there a document.us collection that returns all the base elements? |
| 03:04 | <hays> | What should I read to convince me that the current direction of HTML 5 is not insane? |
| 03:13 | <Hixie> | hays: the spec, probably |
| 03:15 | <crimson_penguin> | Hixie: The spec is what makes him think it's insane, so I doubt reading it again will turn his opinion to the opposite |
| 03:16 | <hays> | So the C spec, for example, has a document that discusses the "why" of certain decisions that is not normative. Python has PEPs. Is there something like that for HTML 5? |
| 03:16 | <Hixie> | yeah, hold on, let me get you some links |
| 03:30 | <hays> | thanks |