#whatwg on 2009-11-03

08:08	<Creap>	While images are at the top of my list of desired medium types in a WWW browser, I don’t think we should add idiosyncratic hooks for media one at a time.
08:08	<Creap>	love that quote
08:08	<Creap>	http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element
08:58	<virtuelv>	mpilgrim: yt?
11:01	<hober>	Is there more recent <head profile> data than http://code.google.com/webstats/2005-12/pageheaders.html ?
11:13	<zcorpan_>	http://philip.html5.org/data/profile-values-2.txt
11:13	<zcorpan_>	http://philip.html5.org/data/profile-values.txt
11:33	<AryehGregor>	Awesome post: http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element
11:37	<virtuelv>	It is
12:26	<Omnipotent>	Hey, where can I find an example for a complete (basic) HTML5 document?
12:27	<jcranmer>	<!DOCTYPE html>
12:27	<jcranmer>	that should be complete, IIRC
12:27	<gsnedders\|work>	You need title too
12:27	<gsnedders\|work>	<!doctype html><title></title>
12:27	<Omnipotent>	Not doctype, document.
12:27	<jgraham>	gsnedders\|work: Damn you. Too fast
12:27	<gsnedders\|work>	jgraham: All your fingers are belong to me.
12:27	<jcranmer>	funny, I always seemed to be able to get pages working w/o titles
12:27	<jgraham>	jcranmer: They won't validate
12:27	<gsnedders\|work>	jcranmer: That's not conforming though
12:28	<jcranmer>	should be :-P
12:28	<jgraham>	Omnipotent: You might want to tighten up your specification
12:28	<jgraham>	Like what do you mean by "complete (basic) document"?
12:29	<gsnedders\|work>	Omnipotent: What we've given you is a conforming HTML 5 document. That fact that it only has a DOCTYPE and a title is beside the point. :P
12:29	<gsnedders\|work>	Omnipotent: It's basic, I think.
12:29	<jgraham>	Omnipotent: (like a complete basic HTML5 blog page is quite different from a complete basic HTML5 email client)
12:29	<Omnipotent>	if I asked that for an HTML4 document, the answer world probably be something like: <!doctype ><html><head><title>blah</title></head><body><h2>header</h2><p>paragraph</p></body></html>
12:30	<Omnipotent>	Only with linebreaks and more readability :P.
12:30	<gsnedders\|work>	You don't need html, head, or body tags.
12:30	<jcranmer>	html and head are definitely optional
12:30	<jgraham>	gsnedders\|work: But there is no harm in having them
12:30	<gsnedders\|work>	<!doctype html><title>Magic</title><h1>Really magic</h1><p>Not that magic
12:30	<jgraham>	You seem to be confusing "basic" with "minimal"
12:30	<Omnipotent>	Yeah, I think they do.
12:30	<gsnedders\|work>	jgraham: Indeed. But minimal is basic. :P
12:31	<gsnedders\|work>	jgraham: (Although they are not synonymous)
12:31	<Omnipotent>	I mean something that will be actually used for a website?
12:31	<jgraham>	gsnedders\|work: That seems like a big leap
12:31	<Omnipotent>	With CSS and all?
12:31	<jgraham>	There is quite a deal of additional complexity to grasp when you miss out tags
12:31	<gsnedders\|work>	<!doctype html><style>body {background:pink; color:blue;}</style><title>Ponies</title><h1>I <3 ponies</h1>
12:31	<jgraham>	(even <tbody>)
12:32	<gsnedders\|work>	That's got CSS and all!
12:32	<jcranmer>	I prefer #abcdef; and #fedcba;
12:32	<jgraham>	Omnipotent: A basic HTML5 page looks like a basic HTML4 page. Basically.
12:32	gsnedders\|work	tries to remember what he was actually working on
12:33	<Omnipotent>	How about new elements like section and article?
12:37	<jgraham>	Omnipotent: <!doctype html><title>My Blog!</title><body><h1>My Blog!</h1><article><h1>My first post</h1>This is a post<section><h1>This I link about this post</h1>Nothing</section></section></body>
12:37	<jgraham>	s/link/like/
12:38	<jgraham>	Oh and one of those </section>s should have been a </article>
12:40	<Omnipotent>	Ty.
12:58	<hsivonen>	http://www.mtv3.fi/uutiset/verot.shtml/arkistot/verot/2009/11/984114
12:58	<hsivonen>	tables being evil taken too far
12:58	<hsivonen>	(view source)
13:03	<Philip`>	I like how the three columns don't actually line up properly
13:04	gsnedders\|work	is guilty of doing similar things himself in the past
13:06	<payman>	jgraham: forgot </html>
13:06	<Philip`>	payman: It was no more forgotten than the <html>
13:07	<payman>	right, my bad
13:08	<gsnedders\|work>	payman: Go learn HTML.
13:08	Philip`	isn't sure whether they were both forgotten or both intentionally omitted
13:08	<Philip`>	seeing as <body> wasn't omitted
13:08	<payman>	lol, ok!
13:10	<jgraham>	Both intentionally omitted
13:10	<jgraham>	Due to laziness but wanting to put all the sectioning elements in
13:10	<Philip`>	Why not omit <body> then?
13:11	<jgraham>	<body> is a sectioning element, no?
13:11	<Philip`>	It's not an element, it's a tag
13:11	<Philip`>	Also, I missed the latter half of your explanation
13:12	<jgraham>	pedant
15:07	<zcorpan_>	importScripts doesn't have the same-origin restriction, right
15:08	<Dashiva>	Is that a script?
15:08	<zcorpan_>	web workers
15:11	<annevk2>	nope
15:27	<Dashiva>	http://twitter.com/marcosc/status/5384964417
15:28	<Philip`>	http://twitter.com/fsasaki/statuses/5378611343 - what's i28n?
15:28	Philip`	's dictionary doesn't have any matches :-(
15:28	<annevk2>	dunno, but the gist of that discussion was that they wanted xml:lang to influence the element language as well
15:29	<annevk2>	xml:lang in no namespace that is
15:33	<Dashiva>	Philip`: It's intergalacticalnationalization
15:35	<beowulf>	preciated
15:36	<beowulf>	wrong window, though the first letter got into the right window...
15:37	<Philip`>	Where did the second letter go?
15:37	<beowulf>	Philip`: presumably it switched the windows?
15:37	<beowulf>	magic irssi p keystroke
15:38	<Philip`>	Ah
15:38	<Philip`>	Odd
15:38	<Philip`>	My irssi has the 'p' key bound to the action of inserting a p in my message
15:38	<beowulf>	probably just my finger mashing typing style :)
15:38	<Dashiva>	I wonder if mrlastweek wants to be found. Some kind of desperate cry for affection.
15:42	<annevk2>	it seems mrlastweek is actually a fan: http://twitter.com/realmrlastweek
15:43	<Dashiva>	Oh indeed
15:43	<Dashiva>	Or maybe he's both of them
15:44	<Philip`>	Maybe they're both fakes
15:45	<Dashiva>	It looks like the blog links to the twitter account, though
15:45	<Philip`>	A cunning ruse
15:49	<Dashiva>	In what way?
15:58	<jgraham>	Philip`: Did you ever look at popular javascript libraries in the dotbot (or any other) data?
16:16	<Philip`>	Dashiva: It's so cunning that I don't know
16:16	<Philip`>	jgraham: Not in any detail (though I do have a file listing all the <script src> values from all the pages)
16:20	<jgraham>	Philip`: That sounds like an interesting file
16:20	<Philip`>	It's a 200MB file so I don't really fancy uploading it
16:21	<gsnedders\|work>	Get a quicker internet connection
16:22	<jgraham>	Get better compression
16:22	<Philip`>	It's still 30MB gzipped
16:22	<jgraham>	That sounds much more bearable depending on what type of connection you are on
16:22	<jgraham>	bzip2 would presumably be smaller still
16:22	<jgraham>	But may not complete
16:23	<jgraham>	by the heat death of the universe
16:23	<Philip`>	I shouldn't need to use my connection since none of the data is on my computer
16:24	<Philip`>	bzip2 is less than 2MB smaller
16:24	<jgraham>	Disappointing
16:24	<jgraham>	So are you willing to upload a 28-30 megabyte file
16:24	<jgraham>	?
16:25	<Philip`>	Most of the effort is in trying to work out how to copy files between two computers
16:26	<Philip`>	Hmm, maybe I could use a fourth computer and rsync
16:30	<jgraham>	As in the old adage "there's no problem involving three computers that can't be solved by adding a fourth"?
16:32	<Philip`>	Hmm, it downloaded to the fourth machine at about 10MByte/sec, but uploading to Dreamhost is incredibly slow
16:33	<jgraham>	Don't you have some cam.ac.uk space somewhere?
16:33	<jgraham>	presumably you have a fast connection to that
16:33	<jgraham>	*.cam.ac.uk I guess
16:34	<Philip`>	Yes but it's probably got silly quotas and stuff
16:34	<Philip`>	and I have a more proper server anyway (the aforementioned fourth machine)
16:34	<Philip`>	but I don't want to fragment my HTML5-related data onto more domains than it's already on
16:35	<Philip`>	http://philip.html5.org/data/script-src-raw.txt.7z
16:36	<Philip`>	(Just all the attribute values seen when parsing, with no particular order and no grouping)
16:36	<jgraham>	Philip`: Thanks
16:37	<jgraham>	Philip`: It is being served as text/plain btw
16:37	<Philip`>	jgraham: Blame Dreamhost
16:37	<jgraham>	Dreamhost: it is being served as text/plain btw
16:37	<Philip`>	Also, can't you decode LZMA in your head?
16:38	jgraham	wonders what he needs to open that file
16:38	<Philip`>	7zip
16:38	<gsnedders\|work>	On a real OS?
16:39	<Philip`>	or a hex editor and the 7zip file format specification
16:39	<Philip`>	It might be called p7zip on some weirdo systems
16:41	jgraham	is sutiably impressed with it working in file-roller as soon as he installs the package
16:52	<GPHemsley>	Hixie: For the record, I second tjeddo's proposal of rel="citation" on <a>
16:52	<Hixie>	amount of support doesn't matter, only the strength of the arguments for or against :-)
16:53	<GPHemsley>	Hixie: Well, read the e-mail. :)
16:53	<Hixie>	will do :-)
17:23	<zcorpan_>	var x; try { importScripts('data:text/javascript,x=1','data:text/javascript,}'); } catch(e) {}
17:23	<zcorpan_>	x should be 1, right?
17:24	<Hixie>	i think so
17:24	<Hixie>	don't see what else it could be
17:24	<zcorpan_>	in firefox it's undefined
17:25	<zcorpan_>	maybe firefox joins the scripts together into one script and then compiles it all at once?
17:25	<Hixie>	seems unlikely, but you can test that theory easily
17:25	<Hixie>	split a script in two
17:26	<Hixie>	and see if it works
17:26	<Hixie>	e.g. var x; try { importScripts('data:text/javascript,x={','data:text/javascript,}'); } catch(e) {}
17:26	<Dashiva>	Maybe it detects parse errors in a separate stage, before executing anything
17:27	<Hixie>	also easy to test
17:27	<Hixie>	e.g. var x; try { importScripts('data:text/javascript,x=1','data:text/javascript,throw 0'); } catch(e) {}
17:28	<gsnedders\|work>	Can someone change http://www.w3.org/Bugs/Public/show_bug.cgi?id=8143 to critical? (as it ought to get into html5lib 1.0)
17:28	<Dashiva>	Also, doesn't hurt to verify that the error is what you except :)
17:29	<hober>	zcorpan_: thanks
17:29	<Dashiva>	*expect
17:29	<Philip`>	Looking at the code, it loads (downloads/compiles) all the scripts, then verifies them all and aborts on failure, then executes them all
17:29	<Hixie>	gsnedders\|work: ask MikeSmith to give you rights
17:29	<Hixie>	(i set it)
17:29	<Philip`>	(and aborts on the first one where execution fails)
17:29	<Hixie>	gsnedders\|work: what's your deadline?
17:29	<Hixie>	gsnedders\|work: i.e. how urgent is this
17:30	<gsnedders\|work>	Hixie: By Friday
17:30	<Hixie>	k
17:30	<Hixie>	can you help me understand the problem? half my brain is listening to this meeting so i can't page in the entire parser model
17:30	<zcorpan_>	var x; try { importScripts('data:text/javascript,x={','data:text/javascript,}'); } catch(e) {} // x is undefined
17:31	<zcorpan_>	var x; try { importScripts('data:text/javascript,x=1','data:text/javascript,throw 0'); } catch(e) {} // x is 1
17:31	<gsnedders\|work>	Hixie: You had with the content model flags a EOF case there, now you don't
17:31	<Hixie>	zcorpan_: they yeah, they syntax check then compile
17:31	<Hixie>	zcorpan_: what does the spec say to do?
17:31	<Philip`>	gsnedders\|work: Why can't you edit it? Bugzilla seems to indicate you have editbugs permission
17:31	<Hixie>	gsnedders\|work: can you say that again in english and with more detail? assume i'm not paying attention. :-)
17:31	<zcorpan_>	Hixie: "For each argument in turn, in the order given, starting with the first one, run these substeps:"
17:32	<Hixie>	zcorpan_: file a bug on them :-)
17:32	<gsnedders\|work>	Hixie: Hey, I have other work-work to do :)
17:33	<MikeSmith>	gsnedders\|work: you should be able to set it yourself now
17:33	<gsnedders\|work>	MikeSmith: Yeah, I appear to be able to now, thx
17:33	<Dashiva>	s/importScripts/importScript/ and the problem disappears ;)
17:34	<gsnedders\|work>	Hixie: Basically, you read rawtext end tag name state, and eventually you have in temporary buffer "xmp", and then you hit EOF. When you hit EOF, we should have a case in that state in the parser which just reprocesses the EOF character in the data state
17:36	<Hixie>	gsnedders\|work: oh you want the characters _not_ emitted?
17:36	<gsnedders\|work>	Hixie: Yeah
17:36	<gsnedders\|work>	Hixie: To match all browsers and the spec before you removed content model flags :)
17:38	<Hixie>	gsnedders\|work: k, can do
17:39	<gsnedders\|work>	Hixie: That's the only issue I've found caused by the content model flag removal, so congrats :)
17:40	<Hixie>	cool
17:42	<Hixie>	so "<style><" is the same as "<style><</style>", "<style></" is the same as "<style></</style>", "<style></s" is the same as "<style></style>", and "<style></stylex" is the same as "<style></style>", but "<style></stylex>" is the same as "<style></stylex></style>"?
17:42	<Hixie>	that seems weird
17:46	<zcorpan_>	surely content doesn't rely on characters not being emitted
17:47	<zcorpan_>	can't we do what's sane here?
17:47	<gsnedders\|work>	We already have interop
17:47	<gsnedders\|work>	It seems risky to change
17:47	<zcorpan_>	ok
17:48	<zcorpan_>	gsnedders\|work: will you fix the html5lib tests?
17:48	<gsnedders\|work>	zcorpan_: They already expect that behaviour because that's what the spec said before the content model flag was removed
17:48	<zcorpan_>	gsnedders\|work: tests16.dat doesn't
17:48	<gsnedders\|work>	zcorpan_: This doesn't effect script data modes
17:48	<zcorpan_>	oh
17:49	<gsnedders\|work>	RCDATA and RAWTEXT
17:49	<gsnedders\|work>	(Though I guess I probably take a look at script data too)
17:49	<gsnedders\|work>	But yeah, I'll update them if need be
17:49	<zcorpan_>	so <script></s means <script></s</script> while <style></s means <style></style>?
17:49	<gsnedders\|work>	That seems bad
17:49	<gsnedders\|work>	I guess we should change script data too
17:56	<Hixie>	i'd much rather make the spec always return the full string unless the end tag was fully recognised
17:56	<Hixie>	i.e. same as the spec now except making EOF be a parse error
18:10	<Hixie>	gsnedders\|work: i think i prefer the way the spec is now than what you're asking for
18:11	<gsnedders\|work>	Hixie: It was deliberately changed to what I was asking for before the content model flag changes
18:12	<gsnedders\|work>	Hixie: Changing it back just because you made a mistake in a zero-black-box changes change seems bad
18:12	<Hixie>	do you remember what convinced me that was a good idea?
18:12	<gsnedders\|work>	No
18:12	<Philip`>	It must have been a good argument, else you wouldn't have changed it
18:13	<Hixie>	hard to argue that
18:13	<Hixie>	but without knowing what it was, maybe it no longer applies
18:13	<Philip`>	It doesn't matter what the argument actually was, it just matters that it exists
18:13	<Lachy>	JohnResig, yt?
18:13	<Hixie>	Philip`: it matters because it might have been predicated on assumptions that no longer apply
18:14	<Hixie>	Philip`: e.g. gsnedders might have bribed me to make one change, but without saying that i couldn't change it back, and so the argument would only work again if he bribed me again.
18:15	<Lachy>	JohnResig, join irc.w3.org:6665 channel #webapps if you want to catch the selectors api discussion soon
18:15	gsnedders\|work	passes Hixie a wad (sp?) of cache
18:15	<gsnedders\|work>	*cash
18:15	<gsnedders\|work>	Silly homophones when I'm sleepy
18:58	<Dashiva>	"Consider removing X", with no rationale given. Smells like success.
19:03	<Hixie>	Dashiva: that's probably a bug i filed as a note to myself
19:03	<Hixie>	during a meeting
19:04	<hsivonen>	can't i18n use lang in n namespace instead of xml:lang in no namespace
19:05	<hsivonen>	@lang works already
19:10	<Hixie>	hsivonen: "it doesn't work in pure xml workflows, for example xpath's language support in xslt only looks at xml:lang in xml namespace"
19:11	<tantek>	what does "pure xml" mean?
19:12	<hsivonen>	Hixie: how does xml:lang in no namespace help, then?
19:13	<AryehGregor>	Presumably for treatment as a polyglot?
19:13	<tantek>	hsivonen, do we then also include xml:id[1] by the same reasoning? [1] http://www.w3.org/TR/xml-id/
19:13	<hsivonen>	Hixie: they should be running the V.nu parser in the mode that maps lang in no namespace to lang in the http://www.w3.org/XML/1998/namespace namespace
19:13	<hsivonen>	tantek: what reasoning?
19:13	<tantek>	to include xml:lang
19:14	<hsivonen>	tantek: no, xml:id got voted off the island
19:14	<tantek>	and xml:lang did not? (for the same reasons)
19:14	<hsivonen>	tantek: xml:lang already got in
19:15	<hsivonen>	lang in the http://www.w3.org/XML/1998/namespace namespace that is
19:15	<hsivonen>	tantek: I think we shouldn't give into i18n on xml:lang in no namespace
19:15	<tantek>	hsivonen - that's my point. I think I am agreeing with your position.
19:16	<hsivonen>	xml:lang is so har to talk about (xml:lang in no namespace vs. lang in the http://www.w3.org/XML/1998/namespace namespace)
19:17	<tantek>	hsivonen - from a web authoring perspective, I'd prefer no form of "xml:lang" - just use "lang" as defined in HTML.
19:17	<hsivonen>	tantek: me too
19:18	<hsivonen>	tantek: but I still rpovide software that lets people write thei XML pipelines as if the were dealing with lang in the http://www.w3.org/XML/1998/namespace namespace when the source says lang="..."
19:18	<hsivonen>	*provide
19:18	<hsivonen>	*their
19:18	<hsivonen>	*they
19:18	<hsivonen>	typo++
19:24	<Hixie>	hsivonen: they were saying they didn't want to serialise to text/html, they just wanted to output a polyglot document
19:24	<Hixie>	hsivonen: the argument against it, i think, would be to say that we don't want to encourage polyglot documents, but in that case we should also drop xmlns, />, etc
19:26	<hsivonen>	Hixie: I don't buy "don't want" as a strong reason
19:26	<hsivonen>	Hixie: is there a "can't" about using a text/html serializer?
19:27	<Hixie>	dunno, i didn't get into this much
19:28	<hsivonen>	I always wonder if people who say they want polyglot doc for XSLT/XPath have tried my XSLT4HTML sample app
19:30	<Hixie>	gsnedders\|work: i'm gonna reject the bug for now, but let me know if you can find the reason why we changed it in the first place.
19:46	<TabAtkins>	What's shepazu's email address?
19:51	<roc>	"Doug Schepers" <schepers⊙wo>,
19:51	<TabAtkins>	Danke, roc.
19:54	<Hixie>	hsivonen: where did you see the language thing btw?
19:58	<AryehGregor>	TabAtkins, FWIW, I'm often not around in the day now (I'm at school), but I can respond when I get home if you leave a message. Also, BTW, your gradient syntax is awesome.
19:59	<AryehGregor>	background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#0AE), to(white)); background-image: linear-gradient(#0AE, white); <http://aryeh.name/css/main.css>;
19:59	<TabAtkins>	AryehGregor: Heh, k. I couldn't recall if you knew any Hebrew, and we were having a discussion that could have used some experience with Hebrew typographic conventions yesterday in the csswg.
19:59	<AryehGregor>	Yes, I know Hebrew.
19:59	<AryehGregor>	What's the question?
20:00	<TabAtkins>	Okay, this is a touch confusing, so follow closely.
20:00	<TabAtkins>	You have an element. Half is in Latin, half is in Hebrew. (any rtl language would work, but Hebrew's the main one that comes to mind)
20:00	<TabAtkins>	You've got white-space:pre, overflow:hidden, and text-overflow:ellipsis.
20:01	<MikeSmith>	hsivonen: what's XSLT4HTML?
20:01	<TabAtkins>	The element is wide enough to contain all of the latin text, and only half of the hebrew text.
20:01	<TabAtkins>	What part of the hebrew text is rendered, what is cut off, and where is the ellipsis placed?
20:01	<Philip`>	MikeSmith: An HTML5 parser and an XSLT processor and an HTML5 serializer, if I rememberr correctly
20:01	<Philip`>	s/rr/r/
20:01	<AryehGregor>	Well, I can give you an example. Look at my own website's <title> when the tab width is too small for all of it to display: http://aryeh.name/
20:02	<Philip`>	in a handy command-line form
20:02	<AryehGregor>	Both Chrome and Firefox cut off the last logical word of the Hebrew, even though it would display further to the left normally.
20:02	<roc>	the first visual half of the Hebrew text (the second logical half) should be rendered, the rest cut off
20:02	<AryehGregor>	Chrome puts the ellipsis in the middle, between the RTL and LTR text, while Firefox 3.7 nightly puts it all the way to the right.
20:02	<TabAtkins>	The last logical word? So the part that's in the visual center of the span?
20:03	<AryehGregor>	Yes.
20:03	<roc>	Firefox doesn't support text-overflow
20:03	<TabAtkins>	roc: That's what I and others think is most reasonable/sane.
20:03	<roc>	our "Hebrew guy" agreed
20:03	<roc>	way back when we discussed this long ago
20:03	<TabAtkins>	roc: But some think that it's best to stick to logical order and have ellipses in the middle. Which makes things crazy.
20:03	<roc>	yes, it does
20:03	<AryehGregor>	Well, I would defer to an Israeli, since they read more mixed-text stuff than I do.
20:03	<roc>	crazy: bad
20:04	<TabAtkins>	We really want to make text-overflow a purely rendering-time construct, not something that gets applied during layout-time.
20:04	<AryehGregor>	roc, Firefox 3.7 doesn't seem to behave the way you describe for <title>s in tabs.
20:04	<roc>	TabAtkins: right
20:04	<TabAtkins>	You should just be able to layout text normally, then at render-time chop out the overflowing bits and swap an ellipsis in.
20:04	<roc>	AryehGregor: yeah, well that's different, and probably wrong
20:05	<TabAtkins>	We've established that browsers currently do things that are probably bad for text-overflow.
20:05	<AryehGregor>	I dunno, Chrome's behavior (truncate last logical word and put ellipsis in the visual middle) seems nicest to me. But it seems arguable.
20:05	<roc>	I'm quite sure that XUL's text-overflow-alike feature was not designed with the niceties of mixed-direction text in mind
20:06	<TabAtkins>	We had a similar example with hebrew first and latin second, and we all agreed that the first logical part of the Latin text should be cut off and ellipsized on the left side.
20:06	<AryehGregor>	Opera seems to act insane. I see only the two letters לע before the ellipsis, which aren't present anywhere consecutively in the text being truncated, either logically or visually.
20:06	<AryehGregor>	At least not in that order.
20:06	<AryehGregor>	TabAtkins, you mean when the dominant direction is RTL? Then why should it be different going the other way?
20:07	AryehGregor	concludes mixed-direction text is crazy, next question please
20:07	<TabAtkins>	Aryeh: Yes, the document was rtl. And it wouldn't be different - it would be the exact same behavior we want for hebrew being cut off in a ltr doc.
20:07	<TabAtkins>	And yes, bidi is crazy all over the place.
20:07	<AryehGregor>	Okay, the basic options are 1) truncate the last visual part, 2) truncate the last logical part.
20:07	<TabAtkins>	Yes. We want (1).
20:07	<AryehGregor>	Either makes sense, I guess, depends how you look at it.
20:07	<AryehGregor>	Okay, well, then you agree with Mozilla's Hebrew guy (who is he, BTW?), so then that's settled?
20:08	<TabAtkins>	Because (2) means that text-overflow affects layout directly, and most reasonably produce ellipses in the middle of the text.
20:08	<AryehGregor>	Yes.
20:08	<TabAtkins>	Aryeh: Yup, looks so. Woo!
20:08	<jwalden>	I'm guessing smontagu
20:08	<TabAtkins>	s/most/must/
20:08	<AryehGregor>	That's what Chrome does in my tab, an ellipsis in the middle. I think it looks kind of cool. :)
20:09	<AryehGregor>	I'm not sure what "affects layout directly" means.
20:09	<AryehGregor>	Surely you have to at least know where letter and word boundaries are at the point where you do text-overflow.
20:11	<TabAtkins>	AryehGregor: In the examples I discussed, if there is no text-overflow, then the first logical part of the hebrew is cut off. Making it act differently when text-overflow:ellipsis is present would be it affecting layout.
20:12	<TabAtkins>	Yeah, you have to know about character/whatever boundaries to know how much to back off so you can put the ellipsis in, but that can be done at render-time and doesn't affect anything else.
20:12	<roc>	it means that elements, even elements other than text, can be moved by text-overflow
20:16	<TabAtkins>	Also, the (2) behavior is crazy when you mix it with overflow:scroll (which is already wrong in all browsers, but at least there's no question about how to fix that).
20:16	<roc>	it's also crazy when you resize
20:17	<TabAtkins>	Correct, basically identical issue.
20:17	<TabAtkins>	And without the crazy behavior that browsers currently give for text-overflow:ellipsis;overflow:scroll;
20:19	<TabAtkins>	Even worse: latin-hebrew-latin, with the element wide enough to cut halfway through the hebrew. I don't think it's possible to define a sane way to present that even ignoring scroll/resize with (2) behavior.
20:19	<TabAtkins>	If you did resize, you'd have to add hebrew into the middle of the text until it was done, then add latin back onto the end of the text. Crazy.
20:27	<AryehGregor>	I'm unclear about the XML entities discussion. Is it proposed that XHTML5 mandate processing of entities always, or only for certain old non-conforming doctypes?