IRC log of html-wg on 2007-03-31

Timestamps are in UTC.

00:08:02 [gavin]
gavin has joined #html-wg
00:27:36 [Zeros]
Zeros has joined #html-wg
01:07:54 [DougJ]
DougJ has joined #html-wg
01:11:07 [Grauw]
[05:31] <anne> Does anyone actually implement new versions of XSLT?
01:11:35 [Grauw]
I've used XSLT2 extensively. In fact, I couldn't bare to use XLST1 anymore, it just misses too much that I've gotten used to :)
01:13:21 [Grauw]
[04:21] <DanC> Hixie, do you take special classes on how to be rude, or do you just do it naturally?
01:13:22 [Grauw]
ehehe
01:14:10 [Grauw]
there's a fad with making sarcastic remarks about the W3C efforts nowadays, it's honestly not that bad, if perhaps not directly applying to the goals of HTML5
01:15:01 [Grauw]
but anyway
01:21:18 [mjs]
Grauw: I don't think Hixie is the only one to think the TAG's findings are of questionable value
01:21:25 [Grauw]
I'm not saying he is
01:21:43 [Grauw]
saying that there's a 'fad' implies that there are more than one people doing it :)
01:21:52 [dbaron]
I completely disagree with a whole bunch of the findings.
01:22:03 [mjs]
'fad' implies that (a) it's invalid and (b) it will pass
01:23:34 [Grauw]
let's rephrase it then, I think there's a lot of criticism on W3C specs and effort on small details, and specs as a whole are named worthless for that
01:23:56 [Grauw]
whereas the specs as a whole are pretty nice
01:24:22 [Grauw]
e.g. XHTML2 introduces a lot of nice things, so within its own space of existence I would say that you could call it a nice specification
01:24:50 [mjs]
XHTML2 is a bunch of bad ideas poorly specified
01:25:15 [mjs]
to call it a "nice specification" you have to water down the meaning of that phrase a lot
01:25:36 [Grauw]
however some people are critisising that it doesn't specify every implementation detail, and discarding the entire spec or the ideas in it as bad
01:25:46 [Grauw]
or at least make it sound like that, and cause other people to do so
01:26:36 [mjs]
I think many of the ideas in it are also bad
01:26:39 [mjs]
though some are good
01:26:49 [Grauw]
well a lot of it is a matter of perspective
01:26:53 [mjs]
its basic idea of breaking compatibility is bad
01:28:00 [Grauw]
if I hear Anne going on about XML error handling it also makes me cringe :)
01:28:21 [Grauw]
mjs, maybe, that's the key difference that HTML5 does different
01:28:52 [Grauw]
however you should consider the ideas within the space of thought of breaking compatibility (and they didn’t entirely, btw)
01:28:55 [Grauw]
anyway
01:28:58 [Grauw]
I need to go :)
01:29:05 [Grauw]
I'm being called ^_^
01:29:12 [Grauw]
later
01:30:40 [Hixie]
if you look at them in a vaccuum, xforms is a nice spec. xhtml2 is not.
01:30:41 [Hixie]
imho.
01:30:54 [Hixie]
xhtml2 leaves far too much very vague and has basically no ua conformance criteria to speak of
01:31:15 [Grauw]
(not gone yet) I suppose you could indeed say that XForms is a much better spec than XHTML2
01:32:51 [mjs]
xhtml2 is a bad spec qua spec as well as an unsuitable design for the web
01:32:55 [Grauw]
maybe as for XHTML2 what I mean is people should look at the ideas that it has (and people have, you said you have too, and a fair amount ended up in HTML5)
01:33:03 [mjs]
in the case of xforms only the latter is true
01:33:25 [Grauw]
I disagree with that :) I don't see how it's unsuitable for the web
01:33:37 [Grauw]
but anyway, I need to go, so don't remark on that :)
01:34:44 [Hixie]
ideas don't make a spec
01:35:35 [Ashe]
Ashe has joined #html-wg
02:00:40 [DougJ]
DougJ has left #html-wg
02:15:56 [gavin]
gavin has joined #html-wg
03:03:45 [mjs]
mjs has joined #html-wg
03:09:30 [Grauw]
w.r.t. that web architecture document quote, "A data format specification SHOULD provide for version information."
03:10:04 [Grauw]
I don't think you can consider CSS a data format. HTML, maybe, but I think whether or not to include versioning information is not a general rule but rather based on a design decision in the language
03:10:31 [Grauw]
finally, in most XML-based formats, the XML namespace provides sufficient means for versioning
03:10:58 [Grauw]
and no additional version information should be provided. backwards-compatibility breaking changes should change the namespace
03:15:58 [sbuluf]
sbuluf has joined #html-wg
03:46:51 [MikeSmith]
MikeSmith has joined #html-wg
04:08:18 [Zeros]
Zeros has joined #html-wg
04:08:24 [Zeros]
Zeros has joined #html-wg
04:17:45 [DougJ]
DougJ has joined #html-wg
04:23:44 [gavin]
gavin has joined #html-wg
04:23:50 [dbaron]
dbaron has joined #html-wg
04:30:25 [mjs]
mjs has joined #html-wg
04:42:03 [Grauw]
I wish people would stop the debate over <abbr> and <acronym>. There is no way in hell that a screenreader can know <acronym>SMIL</acronym> is to be pronounced like ‘smile’, nor can it know that <acronym>SQL</acronym> has to be pronounced ‘sequel’. Unless it has a list of pronounciations built-in, in which case the author doesn’t need to indicate any distinction in the first place.
04:42:44 [Hixie]
css isn't a data format?
04:42:45 [Hixie]
what is it then?
04:43:01 [Grauw]
the only real solution would be to provide an attribute with a pronunciation key in some phonetic alphabet
04:43:36 [Grauw]
Hixie: what I mean is that it doesn’t convey information
04:43:44 [Grauw]
it merely conveys how to present the information
04:44:01 [jjb]
Grauw: that's why we need to spec in a "phonetic" attribute for <acronym>, to be specified in IPA symbols
04:44:05 [jjb]
(just kidding)
04:44:18 [Grauw]
jjb, yay for unicode ;p
04:44:33 [jjb]
ha, i see you made the joke before i had time to put mine together
04:44:38 [Grauw]
I'm all for that, with the proper IPA symbols ;p
04:45:01 [jjb]
in theory, i wouldn't mind that either, but somehow i think it would't pan out so great in the market...
04:45:07 [Hixie]
you don't think "i want h1s to be rendered in green" is information?
04:45:08 [Grauw]
somehow, ne :)
04:45:28 [Grauw]
Hixie, ... I think you’re missing my point :)
04:45:34 [Hixie]
yes
04:45:41 [Hixie]
i don't understand your point :-)
04:46:37 [Grauw]
to me at information is primarily stuff like address information, etc, something you would express with RDF
04:46:54 [Grauw]
CSS in itself as a format of course conveys information on the presentation
04:47:01 [Grauw]
but it doesn’t carry semantics
04:47:02 [Hixie]
you could express CSS in RDF
04:47:16 [Grauw]
of course you can
04:47:23 [Hixie]
so...?
04:47:23 [Grauw]
but you wouldn't :)
04:47:33 [Hixie]
I wouldn't express _anything_ in RDF
04:47:43 [Lachy]
LOL!
04:48:18 [Hixie]
i don't understand why css is different from html in terms of deserving versioning information
04:48:36 [Grauw]
I don't think it is
04:48:53 [Hixie]
ok then
04:49:09 [Grauw]
I'm not trying to make an argument for versioning information, I said it depends on design decisions of the language
04:49:30 [Grauw]
and that maybe the reference to ‘data format’ could be interpreted as so
04:49:45 [Lachy]
Grauw, when would it ever be a good design desicion to include versioning?
04:49:48 [Grauw]
that it would only cover ‘semantic’ information
04:50:28 [Grauw]
for implementors versioning sucks, but I think there’s been a fair number of arguments presented where it’s useful as well
04:51:19 [Grauw]
even if just so that if you see the document, you know ‘oh it was documented according to this version of the standard. I’ll stick to that than, so that the risk of adding stuff that doesn’t work in the systems it’s intended to be used for is minimal’
04:52:24 [Hixie]
why would a specification's version be useful for that? surely you'd want to specify an authoring subset or at most an implementation version
04:52:37 [Hixie]
language versions have very little bearing on what set of features authors use
04:53:09 [Grauw]
Backbase software has been through three major versions by now, all incompatible
04:53:26 [Grauw]
even among minor versions there have been some incompatibilities (unintentionally, I suppose)
04:54:07 [Grauw]
the version information is not indicated however, because it simply depends on which version of the library is included, and which namespace is used
04:54:20 [Hixie]
right but with HTML you have more than one implementation
04:54:31 [Hixie]
so even with one _language_ version you'll have incompatibilities
04:54:38 [Hixie]
e.g. as now with CSS and HTML and DOM and JS and so forth
04:54:41 [Grauw]
yeah, so that’s why it’s a per-language consideration
04:54:45 [Hixie]
no
04:54:51 [Hixie]
it's a per IMPLEMENTATION consideration at most
04:55:16 [Grauw]
...depends on how well the implementations are done, I think.
04:55:29 [Grauw]
with the browsers, we got unlucky in that it’s kind of a mess
04:55:30 [Zeros]
versioning works if its enforced in the implementation
04:56:05 [Grauw]
but if you look at internet standards like IP, etc
04:56:14 [Grauw]
you can’t really implement it ‘incompletely’
04:56:36 [Zeros]
If Javascript 2 only works when you specify that version there's no room for erroneous mixing in features, and you can fix things later with explicit reference to what set of features you're using
04:57:33 [Grauw]
a problem with a lot of ideas that some people have (like anne's xml-should-have-error-recovery) is that it’s a view that really doesn’t apply to all areas
04:58:02 [Zeros]
Some XML implementations have some level of error recovery :)
04:58:04 [Grauw]
e.g. programming languages are usually not forgiving in their syntax error handling, yet they have been used widely and it forms no obstacle to programmers (rather, a help)
04:58:19 [Zeros]
Webkit doesn't show a yellow screen when it sees a malformed document
04:59:01 [Zeros]
Grauw, the counter argument is that all media decoders (mp3, video etc.) implement error recovery when the file is malformed
04:59:02 [Grauw]
XML is very often used to contain a programming language as well, and for data I also think it would be bad to allow the risk of data being incorrectly error-corrected to say something else than that it actually was supposed to mean
04:59:32 [Grauw]
so it’s very specific to the domain
04:59:44 [Grauw]
same is true for versioning information I think
05:00:05 [Grauw]
or feature indication (pretty much the same thing, but more flexible)
05:00:41 [Lachy]
Zeros, WebKit does show an error for malformed content (although it's not yellow like Mozilla)
05:01:01 [Zeros]
Lachy, it shows the page rendered up until that point, mozilla shows nothing but the error
05:01:05 [Grauw]
Zeros, yeah, I hate malformed MP3s with their stupid pops
05:01:15 [Grauw]
if they just didn’t work at all, people wouldn’t share them
05:01:21 [Grauw]
and I wouldn’t be bothered by them
05:01:22 [Zeros]
Lachy, One is better for programmers, the other for users
05:01:27 [Lachy]
oh, I see what you mean
05:02:11 [Grauw]
I think both approaches are ok, as long as there’s something that forces the programmers of the backend to implement something that never generates invalid XML
05:02:29 [DougJ]
DougJ has joined #html-wg
05:02:59 [Lachy]
unfortunately, that doesn't always happen in reality
05:03:20 [Grauw]
if all browsers support XHTML, it will, for sites that serve XHTML
05:03:24 [Lachy]
There's plenty of systems out there that claim to support XML, but only have tag soup parsers
05:03:30 [Zeros]
Lachy, The major issue I think is that XHTML is trivial to hand author and generate invalid results
05:03:33 [Grauw]
because they’re forced to, in the same manner as programmers are forced to make sure their code compiles
05:03:42 [Grauw]
anyway, have to go (again), I’ll read the backlog when I get back :)
05:03:50 [Zeros]
Its more complicated for your word document to become invalid, so most word documents are valid
05:03:55 [Lachy]
e.g. feed readers, mobile phones, etc. all use tag soup parsers for XML
05:04:13 [Zeros]
With XHTML its pretty easy to introduce an anomaly which would invalidate the entire document.
05:04:24 [Grauw]
my feed reader (Sage) uses a true XML parser, and it works just fine (most of the time ;p)
05:04:32 [Lachy]
there are many that don't, though
05:04:40 [Zeros]
libxml2 works pretty well :)
05:04:59 [Grauw]
sure, and I don’t think that’s a good thing
05:05:00 [Grauw]
anyway
05:07:26 [Zeros]
How long does it usually take for sysreq to respond?
05:08:00 [DougJ]
DougJ has left #html-wg
05:08:54 [Lachy]
Zeros, what's your real name, or the name you use on the mailing list?
05:10:24 [Zeros]
I'm not on the list yet, I filled out the form and realized I entered my last name twice.
05:10:31 [Zeros]
Was going to join
05:10:54 [Zeros]
Can you fix it?
05:11:11 [Lachy]
no, ask Dan or Karl
05:11:20 [Zeros]
alright, thanks
05:11:40 [Lachy]
typing /whois says your name is Elliot. What's your last name?
05:11:46 [Zeros]
Elliott Sprehn
05:12:18 [Zeros]
and you?
05:12:22 [Lachy]
Lachlan Hunt
05:13:02 [Zeros]
I guess I'm not anyone
05:53:24 [Lachy]
the logs from in here last night are funny :-)
05:53:41 [Lachy]
especially the stuff about the TAG
06:16:59 [marcos]
marcos has joined #html-wg
06:30:13 [gavin]
gavin has joined #html-wg
06:50:33 [DougJ]
DougJ has joined #html-wg
07:56:31 [chaals]
chaals has joined #html-wg
08:10:55 [anne]
That removing namespace-well-formedness in XML somehow makes documents no longer trustable is a myth. If a document needs to be trustable you verify whether or not it meets your criteria. You can't trust a document solely based on the syntax. That'd be silly.
08:11:25 [anne]
anne has left #html-wg
08:13:05 [anne]
anne has joined #html-wg
08:29:17 [ROBOd]
ROBOd has joined #html-wg
08:38:13 [gavin]
gavin has joined #html-wg
09:04:18 [Grauw]
anne, I’m not saying that you should trust a document based on the syntax. I am saying however that if there’s something wrong with the document, it’s better if it fails with an error than that it silently tries to recover it (very possibly incorrectly), and the source is never notified of the problem
09:06:14 [Grauw]
when it’s meant to be read only by a human (e.g. HTML), it’s less of a problem, because if a human sees, say, that a whole paragraph is linked instead of a certain phrase (because an </a> tag was forgotten), he’ll think it quirky but will understand that only the first part was supposed to be linked.
09:07:06 [Grauw]
a computer however would consider the whole rest of the paragraph to be part of the link description
09:08:07 [Grauw]
HTML recovers from errors, XML does not. Let the people who want error recovery just use HTML and let’s keep XML simple the way it is :).
09:09:13 [Grauw]
it’s not as if XML doesn’t define error handling; it just has very strict (and simple) rules for error handling, similar to say, every programming language out there, or any file system, or any database format
09:09:47 [Grauw]
try writing a bunch of corrupted bytes into a MORK file and see if it still works :)
09:10:01 [Grauw]
it’s not uncommon practice at all, and it’s not a bad practice either
09:10:36 [anne]
I'm not really convinced by your argument.
09:10:47 [anne]
If there's consistent error handling what's the problem?
09:11:00 [Grauw]
because the error is a condition that should not be there in the first place
09:11:16 [anne]
Why should be strict on syntax but loose on conformance?
09:11:18 [Grauw]
it signals that there’s something wrong, and ignoring it and just going on as if nothing happened doesn’t indicate the error
09:11:31 [anne]
s/should//
09:12:13 [Grauw]
loose on conformance? that’s up to the language that is implemented
09:12:57 [Grauw]
for a data file format (what XML was originally envisioned for, I think), I don’t think you would want anything but strict error handling
09:13:30 [Grauw]
and for XHTML, well, it’s in my experience a really nice way to find out some obvious errors that you made, which could otherwise bite you later on
09:13:32 [anne]
Seeing the feeds deployed on the web I think you do want "graceful" error handling
09:14:02 [anne]
Also seeing the XHTML deployed by the way... Event the application/xhtml+xml sites very often have character encoding issues.
09:14:09 [anne]
s/Event/Even/
09:14:18 [Grauw]
the problem is that if the user agent doesn’t implement the file format correctly, it doesn’t
09:14:44 [Grauw]
define error handling conditions as much as you want, a user agent that uses a regular expression to filter out the bits of an XML file still won’t get it right
09:15:01 [anne]
Regular expression?
09:15:10 [Grauw]
there’s plenty of feed readers which do that
09:15:53 [Grauw]
if they would use a real parser (e.g. in Java or .NET or PHP), all of them break on error conditions
09:16:00 [anne]
Oh, I'm talking about the survey done on feeds some time ago and experience people involved in feeds have shared so far.
09:16:55 [Grauw]
if validators use a real XML processor, then feeds must be valid XML
09:17:05 [Grauw]
if they are not, then they are not an XML file format, but something like HTML
09:17:11 [Grauw]
the parsing rules would depend on the user agent
09:17:19 [Grauw]
not on any specification
09:17:58 [Grauw]
if you define error handling cases for XML, the parsers that don’t get it right now, will still not get it right if you specify error handling cases (because they just do their own thing and don’t implement any specification)
09:18:15 [Grauw]
if they had done so in the first place, there would never be so much invalid feeds around on the net
09:18:43 [Grauw]
and anyway, sites who serve feeds can be notified of the problem, it’s a matter of evangelisation I’d say
09:19:20 [Grauw]
anyway, my point is: the XML error handling rules are VERY simple. Making them more complex isn’t going to get more UAs to implement them correctly. If anything, less.
09:19:36 [anne]
Graceful error handling isn't necessarily harder.
09:20:04 [hsivonen]
Grauw: having done standards evangelization for the Mozilla project long ago, my faith in the power of standards evangelism is not very high as a solution to problems like this
09:20:15 [anne]
I also share that concern.
09:20:23 [Grauw]
it doesn’t serve a purpose, if there is strict error handling then authors are enforced to serve correct XML
09:20:51 [anne]
Especially with all the people advocating valid HTML code having an incorrect site themselves...
09:20:55 [Grauw]
if the XML is invalid then you cannot be sure the error handling corrects it properly
09:21:06 [Grauw]
I don’t :)
09:21:21 [anne]
You can never be sure.
09:21:25 [Grauw]
because I use XHTML at least I don’t make obvious mistakes like forgetting a </a> :)
09:21:37 [anne]
You also can't be sure the parser correctly rejected your content.
09:21:52 [Grauw]
it’s like a programming language: there being syntax checking and type checking doesn’t guarantee that your program is good or well-written
09:22:09 [Grauw]
it does help you catch a lot of obvious errors though
09:22:11 [anne]
Or did not reject your content when in fact it should. (A common problem with today's browsers.)
09:22:37 [Grauw]
on my website there’s in fact two layers of XML parsers that check it, the backend and the browser itself
09:22:42 [anne]
A conformance checker helps you with that and more.
09:22:56 [anne]
(I wasn't talking about your website specifically.)
09:22:59 [Grauw]
a conformance checker exists on an entirely different layer
09:23:05 [Grauw]
it isn’t immediate
09:23:13 [anne]
It could be
09:23:14 [Grauw]
people run it after developing the site as an afterthought
09:23:21 [Grauw]
and don’t run it again everytime new content is added
09:23:33 [anne]
That entirely depends on how you do things.
09:23:44 [anne]
If they don't doing just syntax checking on new content doesn't help much.
09:23:48 [anne]
imo
09:23:48 [Grauw]
XML does it inherently
09:24:05 [anne]
No, XML only checks some syntax of which some isn't even enforced in all browsers.
09:24:29 [anne]
You can't really buy anything with that.
09:24:30 [Grauw]
besides, if the parser doesn’t reject the XML, it’s a parser bug. Defining graceful error handling rules isn’t going to improve that situation because the parser doesn’t follow the spec!
09:24:53 [Grauw]
browsers isn’t the only thing out there
09:25:20 [anne]
I'm not sure I ever argued otherwise.
09:25:34 [Grauw]
the fact that some browsers may implement some parts of XML badly doesn’t make it useless, or a failure
09:25:47 [hsivonen]
Grauw: I wouldn't be too surprised if even Xerces-J didn't properly enforce well-formedness for non-UTF-* documents
09:26:10 [anne]
It makes it a failure on lots of mobile content and lots of feed content.
09:26:14 [anne]
Sadly.
09:26:46 [hsivonen]
the thing is that XML works great as long as you don't expose authors to it or put it on the Web
09:27:04 [Grauw]
so pointing to bad implementations, how exactly does that make ‘graceful’ error handling better? an error is an error.
09:27:11 [hsivonen]
XHTML and RSS are the cases where people start to complain about this
09:27:20 [Grauw]
that’s a good thing
09:27:23 [hsivonen]
the enterprise integration use cases are fine
09:27:27 [Grauw]
it finally forces people to pay attention
09:27:32 [anne]
Also, again, there's not much point in enforcing strict syntax if you don't enforce all the other things a document needs to conform too as strict as well. (And that's impossible for XHTML for instance and any other language that allows embedding script.)
09:27:47 [Grauw]
I wouldn’t say there’s no point
09:28:03 [Grauw]
for one thing, XML lives on a different layer than the document language on top of it
09:28:16 [Grauw]
breaking XML well-formedness breaks any type of processor
09:28:56 [Grauw]
I mean, you don’t go blaming IPv4 for errors in HTML documents either
09:29:03 [anne]
Not for syntactically correct content, but yes.
09:29:47 [anne]
I would say that HTML syntax and XML syntax are on the same layer more or less...d
09:29:53 [anne]
s/...d/.../
09:29:55 [Grauw]
or rather, I do not expect IPv4 to be ‘lenient’ in some unpredictable way (and instead of rejecting bad packets routing them anywhere based on a guess) just because there are bad HTML documents out there
09:30:09 [Grauw]
syntax, yes
09:30:17 [Grauw]
SGML too
09:30:19 [anne]
AFAIK authors don't have to deal with IPv4 so that seems fine.
09:30:30 [anne]
SGML is pretty much dead.
09:30:38 [Grauw]
beside the point :)
09:31:06 [Grauw]
it’s on the same layer, HTML syntax is a variant of SGML and XML is a variant SGML too
09:31:25 [Grauw]
however the language that uses XML (tons) or the language that uses HTML syntax (HTML itself) are on a higher layer
09:31:36 [anne]
XML is actually a subset iirc
09:31:49 [Grauw]
last I read it wasn’t entirely SGML-compatible
09:32:04 [Grauw]
but I might be mistaken, anyway, subset falls under the variant nomer I think :)
09:32:29 [Grauw]
higher layer, just like the Java API is on a higher layer of the Java syntax, yet it’s also part of the same language
09:32:35 [anne]
I'm not sure why "higher layer" matters here.
09:32:39 [Grauw]
s/of/than
09:32:47 [anne]
It's the syntax you use as author.
09:32:56 [Grauw]
XML is used in a lot more ways than HTML alone
09:33:01 [anne]
The language itself would actually be the "higher layer" imo...
09:33:09 [Grauw]
for a lot of applications of XML, strict error checking is simply inappropriate
09:33:27 [Grauw]
for XHTML, strict error checking is a good thing as well I think
09:33:32 [Grauw]
it avoids a lot of problems
09:33:36 [Grauw]
not all, but a lot
09:33:38 [anne]
Which problems?
09:33:44 [Grauw]
forgetting an </a> tag
09:33:47 [anne]
It only avoids some syntax problems...
09:33:58 [anne]
Which are obvious when you make them anyway...
09:34:20 [Grauw]
I’ve seen plenty of sites / blog posts where an entire paragraph was a link because people forgot an </a>
09:34:27 [hsivonen]
Grauw: do you mean that there are cases when a DTD-valid XML document is not an SGML + Annex K document?
09:34:48 [Grauw]
hsivonen: you tell me, I don’t know, I just think I read it somewhere :)
09:34:55 [anne]
Grauw, prolly with an XHTML DOCTYPE
09:35:03 [Grauw]
or posts where the </ul> in a list was forgotten, causing the indenting to be wrong in my feed reader but not in browser X
09:35:27 [Grauw]
anne, what has doctype to do with it :)
09:35:36 [anne]
nm that
09:35:39 [Grauw]
except for determining ‘standards’ or quirks mode in IE
09:35:54 [anne]
I rather have the content as user than some error in my face because the author just pressed publish and walked away.
09:36:04 [Grauw]
I understand that
09:36:06 [anne]
Or didn't check in all user agents...
09:36:10 [Grauw]
one sec
09:36:18 [anne]
(Which happens, I posted samples of that to my site.)
09:36:35 [anne]
Not just in Internet Explorer...
09:38:37 [Grauw]
IE doesn’t understand XHTML, so there’s no user agents on the web which don’t at least have a decent understanding of XML
09:39:12 [anne]
?
09:39:50 [Grauw]
if you author XML, processed by an XML parser, then you should never be presented with a page that’s unreadable because the author didn’t verify the XML-well-formedness
09:40:05 [Grauw]
because the author’ll notice that his page is broken immediately
09:40:38 [Grauw]
or of course, really because his CMS ran it through a server-side XML parser to test the well-formedness and complains if it isn’t
09:42:34 [Grauw]
anyway, if you really want graceful error degradation, use HTML instead of XHTML. If you care about the same in feeds, well honestly, just use an XML parser and let the users complain to the author’s website to fix it :).
09:42:55 [Grauw]
I’ve done so to a site that newly had an XML feed implemented, and that worked just fine.
09:42:57 [anne]
I also care about it on mobile phones.
09:43:26 [anne]
I also think the character encoding issue would have had to be fixed by now in order for that to be feasible. But it isn't...
09:43:31 [Grauw]
I don’t think there’ll be documents that are authored on a mobile phone
09:43:34 [hasather]
hasather has joined #html-wg
09:43:44 [anne]
Also, I think ease of authoring and users first demands graceful error handling.
09:43:59 [anne]
Grauw, you obviously don't work for the same company as I do
09:44:08 [Grauw]
If the desktop browsers are all strictly validating, and they don’t use some different ‘profile’ or something but just the same content, then they should be authored correctly even if some phones don’t have a proper XML parser
09:44:40 [Grauw]
I have worked with a lot of XML technologies though, and also on the support side of that.
09:44:46 [anne]
We are encountering those problems daily and are currently using heuristics (last I heard) to determine whether or not application/xhtml+xml can be processed as XML...
09:44:56 [Grauw]
Backbase processes all documents as XML, and the worst we get as support questions is like
09:45:10 [Grauw]
‘why doesn’t &nbsp; work’ and we tell them to use ‘&#160;’ and they’re happy.
09:45:44 [Grauw]
I don’t see the need for those heuristics
09:45:55 [Grauw]
you are planning, huh :)
09:46:40 [anne]
Yeah, next semester I'll be working on XML2 as part of my university research project for my Bachelor degree.
09:46:50 [anne]
or XML5, haven't decided on a name yet
09:47:12 [Lachy]
oh, not another naming debate ;-)
09:47:28 [Grauw]
I think I could say I probably have more experience with XML technologies than you do, given that Backbase is based on XML, and your work mainly concerns HTML :)
09:47:49 [anne]
Lachy, just between me and my supervisor at the uni this time...
09:48:16 [anne]
Grauw, how do you know what my work concerns?
09:48:43 [anne]
But "XML technologies" sure...
09:48:43 [Grauw]
I don’t know, you started the ‘you obviously don’t work for the same company as I do’ path :)
09:48:44 [hsivonen]
anne: my supervisor first favored "Web Applications 1.0" but later agreed to putting "HTML5" in the title
09:49:16 [anne]
Grauw, I was just indicating that you can't know the problems we face with mobile content.
09:49:58 [hsivonen]
anne: do you mean the success story of XML for mobiles is breaking XML? :-)
09:49:58 [Grauw]
well I know of a lot of XML-related problems because Backbase is actually one of the few web technologies that uses XML
09:50:08 [anne]
hsivonen, sort of :)
09:50:36 [Grauw]
and we don’t get many of them
09:51:22 [Grauw]
writing correct XML is actually extremely simple compared to writing correct HTML :)
09:51:44 [Grauw]
most people who don’t get it at first do get it soon thereafter
09:52:36 [anne]
That's good. I don't plan to change how you have to write XML.
09:52:47 [Grauw]
as for Opera, given that they have a fairly wide deployment, they are likely a tested platform for many mobile web sites (as they really test against platforms anyway), and it would be nice if they stood ground with regard to XML validity
09:53:12 [anne]
XML validity?
09:53:13 [anne]
hah
09:53:18 [Grauw]
well-formedness
09:53:26 [Grauw]
you get what I mean
09:53:29 [anne]
You mean namespace-well-formedness?
09:53:48 [anne]
As I said, we tried and failed.
09:53:56 [Grauw]
I don’t think I have ever heard of namespace-well-formedness so far
09:54:17 [Grauw]
Maybe Opera gave up too soon :)
09:54:29 [anne]
<test:test/> is well-formed but not namespace-well-formed
09:54:56 [anne]
You can speculate all you wish, but reality is what matters here.
09:55:10 [anne]
Oh, its "namespace well-formedness"
09:55:27 [anne]
See http://www.w3.org/TR/xml-names/#ProcessorConformance
09:55:28 [Grauw]
Namespace well-formedness then, yes
09:56:29 [Grauw]
the problem why there is invalid XML in the first place is because UAs give in to pressure like Opera does
09:56:38 [Grauw]
and many, many feed readers
09:57:08 [anne]
The problem is that people are not perfect.
09:57:13 [anne]
And make imperfect products.
09:57:30 [anne]
And we have to deal with that situation and not just pretend it doesn't exist.
09:57:31 [Grauw]
they seem to have no problem with well-formedness when creating a Java program
09:57:44 [Grauw]
So I don’t buy into the argument that people can’t help doing it wrong
09:57:54 [anne]
People have lots of problems with different C compilers every day...
09:57:54 [Grauw]
or that doing it right is so hard that it’s impossible
09:58:07 [Grauw]
that’s a very different issue
09:58:09 [hsivonen]
if there's some pressure point where I wish Opera had stood firm, it's that I think all browser vendors should have refused to implement XML 1.1
09:58:12 [anne]
I don't know enough about Java.
09:58:27 [Grauw]
but it would be great if C compilers would agree on one language
09:58:41 [anne]
hsivonen, I think I'll fold in all the good features from XML 1.1 into XML n
09:58:59 [Grauw]
XML 1.1 is XML 1.0 plus a wider unicode range, right?
09:59:16 [anne]
Plus at least one incompatible change...
09:59:35 [anne]
wider unicode range for element and attributes names btw
09:59:39 [Grauw]
yes
09:59:51 [Grauw]
the incompatible change being (if it’s easy to describe)?
09:59:53 [hsivonen]
Grauw: XML 1.1 allows a different arbitrary range of characters (yes, wider) in element and attribute names
10:00:00 [anne]
Grauw, the spec points them out
10:00:11 [anne]
some characters are no longer allowed in some production
10:00:13 [anne]
and some others are
10:00:19 [Grauw]
aha
10:00:36 [Grauw]
well that’s weird, that they exclude characters that used to be allowed before
10:00:57 [hsivonen]
the path to crazy implementation cost and interop breakage is paved with i18n political correctness and IBM mainframe compat
10:01:11 [anne]
XML 1.1 is a classic example of versioning done wrong
10:01:13 [Grauw]
unless they were characters that could not actually be used in a regular document
10:01:34 [Grauw]
anyway, I need to go :)
10:01:38 [Grauw]
(again!)
10:01:44 [Grauw]
see you later
10:01:44 [anne]
heh
10:01:49 [anne]
bye
10:01:58 [anne]
http://www.w3.org/TR/xml11/#sec-xml11
10:04:29 [anne]
The main problem is the control character nonsense.
10:05:05 [hsivonen]
anne: what exactly is the nonsense in your opinion_
10:05:06 [hsivonen]
?
10:05:35 [anne]
That you need to use character references and such...
10:06:09 [anne]
I don't think those changes make much of a problem though... Just allow everything and require #0 to be translated to #FFFD
10:06:18 [anne]
#x0 to #xFFFD
10:07:08 [anne]
So new parsers can just ignore the whole <?xml version=x?> thing and continue...
10:08:09 [hsivonen]
anne: would you allow #xFFFF?
10:08:41 [anne]
everything that should not be allowed for some good reason will be translated into #xFFFD during the input stream phase I suppose
10:08:49 [hsivonen]
anne: would #x0 be the only code point that you would not allow in the infoset?
10:08:55 [anne]
I'm obviously no expert in that
10:13:00 [anne]
hsivonen, it seems that's what HTML5 does
10:13:19 [hsivonen]
yes.
10:13:51 [hsivonen]
in retrospect, I think it was a very bad idea for XML to arbitrarily limit the lexical space of identifiers
10:13:57 [anne]
Although HTML5 should probably deal with some characters such as those from windows-1252
10:14:11 [hsivonen]
but gotta run to an iki.fi meeting to lobby for a Jabber server
10:14:19 [anne]
bye
10:35:12 [ROBOd]
ROBOd has joined #html-wg
10:43:02 [edas]
edas has joined #html-wg
10:53:20 [gavin]
gavin has joined #html-wg
13:01:07 [gavin]
gavin has joined #html-wg
13:33:41 [erik]
erik has joined #html-wg
13:35:00 [erik]
erik has joined #html-wg
13:36:11 [marcos___]
marcos___ has joined #html-wg
13:49:42 [h3h]
h3h has joined #html-wg
14:29:14 [Shunsuke]
Shunsuke has joined #html-wg
15:08:42 [gavin]
gavin has joined #html-wg
15:12:48 [Grauw]
Grauw has joined #html-wg
15:53:41 [edas]
edas has joined #html-wg
15:58:39 [h3h]
h3h has joined #html-wg
16:13:25 [sbuluf]
sbuluf has joined #html-wg
16:15:24 [hasather]
hasather has left #html-wg
16:16:27 [cwahlers]
cwahlers has joined #html-wg
16:52:09 [st]
st has joined #html-wg
17:00:57 [dbaron]
dbaron has joined #html-wg
17:16:00 [gavin]
gavin has joined #html-wg
18:08:45 [edas]
edas has joined #html-wg
19:22:52 [gavin]
gavin has joined #html-wg
19:55:18 [hasather]
hasather has joined #html-wg
20:00:46 [edas]
edas has joined #html-wg
20:28:47 [h3h_]
h3h_ has joined #html-wg
20:39:40 [hasather]
hasather has joined #html-wg
21:30:20 [gavin]
gavin has joined #html-wg
23:09:12 [hasather]
hasather has left #html-wg
23:25:12 [Zeros]
Zeros has joined #html-wg
23:38:15 [gavin]
gavin has joined #html-wg