16:22:27 <RRSAgent> RRSAgent has joined #core
16:22:27 <RRSAgent> logging to http://www.w3.org/2010/06/07-core-irc
16:22:37 <fantasai> Meeting: Bidi F2F @ Google
16:22:44 <fantasai> Introductions
16:23:49 <fantasai> Aharon: Goal is to have consensus within this room, then reach outward for feedback and file bugs against CSS/HTML/etc
16:24:30 <TabAtkins_> TabAtkins_ has joined #core
16:25:54 <Norbert> Norbert has joined #core
16:26:34 <ehsanakhgari> ehsanakhgari has joined #core
16:26:41 <Aharon> Aharon has joined #core
16:26:43 <ehsanakhgari> hi guys
16:26:59 <ehsanakhgari> so, we're on the phone, but apparently we're muted
16:27:05 <najib-ma> najib-ma has joined #core
16:27:17 <najib-ma> hello
16:27:31 <behdad> behdad has joined #core
16:27:35 <Aharon> hi, najib
16:27:40 <roozbeh> roozbeh has joined #core
16:27:43 <behdad> hi
16:27:52 <crc> crc has joined #core
16:28:14 <fantasai> Aharon Lanin, Google
16:28:30 <adil> adil has joined #core
16:28:36 <behdad> hey.  Behdad Esfahbod, Red Hat / GNOME (call in from Toronto with ehsanakhgari)
16:28:37 <roozbeh> Mati Allouche, IBM
16:28:38 <adil> Hello!
16:28:49 <ehsanakhgari> I'm Ehsan Akhgari, Mozilla Corporation
16:28:52 <Norbert> Norbert Lindenberg, Yahoo
16:28:54 <roozbeh> Bob Jung, Google
16:28:59 <roozbeh> Mark Davis, Google
16:29:02 <crc> crc has joined #core
16:29:08 <fantasai> Elika J. Etemad aka fantasai, W3C CSSWG Invited Expert
16:29:17 <roozbeh> Craig Cummings, Yahoo
16:29:30 <roozbeh> Xiaomei Ji, Google
16:29:33 <najib-ma> Najib Tounsi, Teacher at University Rabat. Also Morocco W3COffice  manager 
16:29:36 <roozbeh> Roozbeh Pournader, HighTech Passport/GNOME/Yahoo
16:29:54 <fantasai> Tab Atkins, Google, HTMLWG + CSSWG
16:30:04 <adil> Adil Allawi - Diwan Software
16:30:14 <fantasai> Scribe: fantasai
16:30:36 <Aharon> agenda: https://docs0.google.com/document/edit?id=1i3a4uPufe5mpKqF27GgH0lz_UlzlRtpGz1kiT-hG8vI&authkey=undefined#heading=h.dghw7g-xw78cu
16:30:59 <fantasai> Aharon: These are the open issues that I've identified so far in the proposal s it is in the first public wd
16:31:11 <behdad> fantasai: thanks! :)
16:31:12 <fantasai> Aharon: This session I would like to talk about section 2.1, which is bidi isolation through a new HTML attribute
16:31:21 <fantasai> Aharon: and some related issues in 3.1 and 3.3
16:31:31 <fantasai> Aharon: I sent an email yesterday with a discussion on that subject
16:31:49 <fantasai> Aharon: First let's look at the open issues
16:31:59 <fantasai> (email is http://lists.w3.org/Archives/Public/public-i18n-bidi/2010AprJun/0063.html )
16:32:21 <fantasai> Aharon: First issue is that bdi name is not a good choice. Sounds like bidi, means something more specific
16:32:27 <fantasai> Aharon: Also very cryptic.
16:32:34 <fantasai> Aharon: We might as well choose a better tentative name
16:32:37 <fantasai> Aharon: There have been two proposals
16:32:50 <fantasai> Aharon: One from Najib, for sce - "Self-Contained Entity"
16:33:01 <fantasai> Aharon: Also a cryptic acronym, but tries to say something more general
16:33:22 <fantasai> Aharon: Najib also suggested besides having an attribute name also having an element, equivalent to span with the attribute
16:33:31 <fantasai> Aharon: My alternate suggestion is 'dirsep'
16:33:38 <fantasai> Aharon: Thought it was pretty clear
16:33:51 <fantasai> Aharon: Don't want to make the name too long, since this will be commonly used in internationalized apps
16:34:15 <fantasai> Behdad: I suggest adding this to unicode-bidi instead of HTML
16:35:15 <najib-ma> q+
16:35:24 <adil> agreed
16:35:37 <fantasai> fantasai: While I believe this functionality should be expressed through unicode-bidi as well, I think it belongs in the markup.
16:36:07 <roozbeh> behdad, I'm not sure I understand what you suggested.
16:36:28 <fantasai> roozbeh, behdad suggests adding a new value for isolation to the CSS unicode-bidi property
16:36:28 <behdad> roozbeh: there's the CSS unicode-bidi attr. 
16:36:35 <roozbeh> Ah, ok.
16:36:42 <roozbeh> That one.
16:36:44 <behdad> which is actually very close to what's being proposed (unicode-bidi: embed)
16:37:04 <fantasai> Aharon: So we seem to have agreement that bdi, under a different name, will be both an HTML attribute and a CSS equivalent, details to be discussed later
16:37:39 <fantasai> Aharon: Are there any other suggested names?
16:37:40 <roozbeh> behdad, got it.
16:37:46 <fantasai> fantasai: bds for bidi-separation?
16:37:48 <behdad> can't we have "bidi" and have values match css?
16:38:28 <roozbeh> behdad, please bring it on on the phone.
16:38:34 <fantasai> Najib: I'm not for sce strictly, but for something expressing that idea
16:38:56 <fantasai> Mark: I really dislike cryptic. SCE doesn't mean anything to anybody, and even once you learn it it doesn't make a whole lot of sense
16:39:05 <fantasai> Mark: I would prefer bidisep or something
16:39:33 <fantasai> Mark: When you say Self-contained entity, is the containment related to bidi only, or are there other concerns?
16:39:49 <fantasai> Aharon: The idea would be to control any similar issues, but we haven't come up with any.
16:40:39 <fantasai> Najib: bidisep is good
16:40:44 <fantasai> Mark: Or even bidi-isolate
16:40:50 <fantasai> fantasai: That's getting really long.
16:41:05 <fantasai> fantasai: For internationalized apps, you will be using this many many times in a page. 
16:41:21 <najib-ma> Mark, sce is related to bidi only
16:41:47 <adil> - if shorter is better - dirsep
16:42:00 <ehsanakhgari> If we have a CSS equivalent, applications can choose to use shorter names if desired and use a selector to tie the functionality to a shorter name
16:42:00 <fantasai> Roozbeh: bidi-iso?
16:42:11 <roozbeh> bidi-isol actually
16:42:17 <fantasai> Aharon, fantasai: separate vs. isolate depends on the definition we choose
16:42:31 <fantasai> ehsanakhgari, not if it's an HTML attribute
16:42:38 <fantasai> ehsanakhgari, which is the goal here
16:42:57 <fantasai> Topic: Separation vs. Isolation
16:43:04 <ehsanakhgari> fantasai: sure, what I'm trying to say is that we probably shouldn't be optimizing for a few less characters in the attribute name
16:44:13 <fantasai> Aharon: So the "Separation" definition is that the isolated entity would be embedded using the base direction of the surrounding text
16:44:30 <fantasai> Aharon: which gives the boundaries a strong directionality in that direction
16:45:08 <fantasai> Aharon: as if surrounded by RLM/LRM characters (as appropriate)
16:45:26 <fantasai> Aharon: However, the implication of this strong directionality is that it not only isolates the content
16:45:34 <fantasai> Aharon: but also separates what comes before it from what comes after
16:46:00 <fantasai> Aharon: An alternate definition, the "Isolation" definition, is to treat the contents as an independent bidi paragraph
16:46:09 <fantasai> Aharon: but to treat the entity as a single neutral character
16:46:15 <fantasai> (e.g. object replacement character)
16:46:25 <fantasai> Aharon: In HTML, this is the behavior of <input> elements.
16:47:26 <fantasai> Aharon: In CSS, there is precedent for this in the 'inline-block' definition
16:47:45 <fantasai> Aharon: The contents are treated as a separate paragraph, and the entire inline-block as a single neutral character
16:48:02 <fantasai> Roozbeh: The second definition is better.
16:48:21 <fantasai> Roozbeh: The first is actually possible right now with bidi formatting chars
16:48:32 <fantasai> Roozbeh: And there are complex cases that can't be handled with the separation definition
16:48:56 <fantasai> Mark: Arguably, we should have treated embeddings like this in the first place
16:49:01 <fantasai> Mark: But that's water a long way under the bridge
16:49:20 <fantasai> Mark: My concern with this -- it sounds like the right thing to do -- my concern is, if you were to copy this text into plaintext,
16:49:27 <fantasai> Mark: How would you display it in plaintext?
16:49:44 <fantasai> Mark: I like the idea of isolation, and I think we should see if there are ways to make it work right in all contexts
16:50:02 <fantasai> Aharon: Before we go on to discuss pros and cons, would like to point out more preliminaries
16:50:10 <fantasai> Aharon: First, conceivably, we might want to offer both.
16:50:18 <fantasai> Aharon: By making bdi not a binary, but one that takes several values
16:50:26 <fantasai> Aharon: And you can choose isolate or separate as you prefer
16:50:29 <fantasai> Aharon: That's a possibility. 
16:50:46 <fantasai> Aharon: It is obviously not something very desirable in and of itself, because it's not something that 99% of users will understand
16:51:04 <fantasai> Behdad: I would like to suggest that the attribute reflect unicode-bidi
16:51:14 <fantasai> Behdad: I believe your proposal is exactly the same as "unicode-bidi: embed"
16:51:30 <fantasai> Behdad: That creates an embedding in the inherited base direction
16:51:50 <fantasai> Behdad: And the unicode bidi algorithm treats the start and end of the embedding as strong directions
16:52:40 <adil> Is there anyone with Google Wave there?
16:52:55 <ehsanakhgari> adil: I can use Wave
16:53:17 <adil> Can you share a wave drawing of the white board?
16:53:35 <ehsanakhgari> Aharon, fantasai: ^
16:53:50 <fantasai> fantasai: So there are basically two things to consider here
16:54:04 <fantasai> fantasai: We assume that the contents are treated as a single entity, i.e. embedded
16:54:07 <TabAtkins_> I'll take pictures.  ^_^
16:54:15 <fantasai> fantasai: The question then is, how are the boundaries treated -- on the inside, and on the outside?
16:54:20 <fantasai> fantasai: Are they strong or are they neutral?
16:54:26 <fantasai> fantasai: You can have the inside neutral and the outside strong
16:54:29 <fantasai> fantasai: or vice versa
16:54:33 <fantasai> fantasai: or both strong
16:54:36 <fantasai> fantasai: or both neutral
16:54:48 <fantasai> <span dir="rtl">HELLO</span> 1.
16:54:56 <fantasai> whiteboard ^
16:55:08 <fantasai> Aharon: LTR context
16:55:16 <fantasai> Aharon: In an LTR context, this would be displayed as
16:55:24 <fantasai> 1OLLEH.
16:55:32 <behdad> right...
16:55:41 <fantasai> Aharon: The 1 gets stuck onto the HELLO on the left, and the period gets put on the right
16:56:13 <fantasai> Aharon: Unicode equivalent is [RLE]HELLO[PDF]1.
16:56:14 <behdad> how about: <span unicode-bidi=embed><span dir=rtl>HELLO</span></span> 1.?
16:57:38 <TabAtkins_> Scribe: TabAtkins
16:57:47 <TabAtkins_> fantasai: What embedding level is the "1" at?
16:57:52 <TabAtkins_> Aharon: At 2.
16:58:08 <fantasai> fantasai doesn't undestand why the embedded contents are not higher than the contents outside them
16:58:14 <fantasai> Mark: I'm getting a different result
16:58:22 <behdad> fantasai: implicit?
16:58:44 <fantasai> behdad, implicit levels should never be higher than embedded ones imo.... 
16:58:45 <roozbeh> unicode.org/cldr/utility
16:58:51 <behdad> digits get a bump (0->2)
16:59:06 <behdad> fantasai: the way css is written it adds one level of embedding.
16:59:13 <roozbeh> http://unicode.org/cldr/utility/bidi.jsp
16:59:21 <fantasai> the bidi spec should jump embedding levels by more than 1 then, 'cuz that's weird!
16:59:23 <behdad> so you get RLE causing 0->1, but implicit can cause 0->2 for digits
16:59:39 <fantasai> yeah, implicit jumping higher than explicit seem wrong to me
16:59:42 <fantasai> even if that's what the spec says
16:59:55 <behdad> it's designed to be that weird, ask Mark :P
17:00:34 <fantasai> Mark: bidi spec says this is a run here, and this is a run here
17:00:39 <fantasai> Mark underlines HELLO and 1.
17:00:41 <fantasai> separately
17:01:05 <fantasai> Mark: There's an implicit start-of-run (SOR) and end-of-run (EOR) at the start and end of the runs
17:01:15 <fantasai> Mark: This is rule X9
17:01:31 <fantasai> Mark: Then is says SOR and EOR are treated as either L or R
17:01:35 <roozbeh> It is X10.
17:01:56 <fantasai> s/X9/X10/
17:02:40 <fantasai> Mark: The SOR and EOR are L or R based upon the higher of the two levels around the boundary
17:03:13 <fantasai> Mark: So the embedded content will be level 1, and the content outside level 0.
17:03:38 <fantasai> Aharon doesn't believe this and shows an example in HTML loaded in Firefox
17:03:47 <fantasai> Mark: We have to look at what does the spec say, and what is implemented
17:03:55 <fantasai> Aharon: Numbers are strange, let me give another example
17:04:22 <adil> http://unicode.org/cldr/utility/bidi.jsp
17:05:03 <fantasai> Aharon writes on the board:
17:05:13 <fantasai> <span dir=rtl>HELLO</span>
17:05:18 <fantasai> THERE
17:05:35 <fantasai> EREHTOLLEH
17:06:11 <fantasai> Aharon: The two stick together
17:06:31 <fantasai> Aharon: This example shows the difference between the proposal, and without the proposal.
17:06:38 <fantasai> Aharon: Whether we have isolation or separation
17:07:03 <fantasai> Aharon: Either way, with bdi, it would be OLLEH EREHT
17:08:47 <fantasai> Aharon: dir=rtl is equivalent to style="direction: rtl; unicode-bidi:embed"
17:08:59 <fantasai> Aharon: Unicode-bidi does not give us either isolation or separation
17:09:07 <fantasai> Mark: Do you think it is necessary to have both?
17:09:16 <fantasai> Aharon: That is something I want to talk about
17:09:27 <fantasai> Aharon: My opinion is that I need separation for a couple of cases
17:09:35 <fantasai> Aharon: And in most cases, the difference is not felt
17:10:11 <fantasai> Aharon: The cases where it does make a difference all boils down to whether you have a case where the text preceding and the text following the bdi element both are of the same implicit direction
17:10:18 <fantasai> Aharon: both are opposite to the general context
17:10:23 <fantasai> Aharon: and neither have bdi
17:10:38 <fantasai> Mark: The problem is when you have a third-level embedding
17:11:29 <fantasai> Aharon erases and draws on the whiteboard
17:11:34 <fantasai> LTR context
17:13:04 <fantasai> read "DEAR <span bdi (dir=ltr)?>john</span> AND SUSAN" today
17:13:16 <fantasai> (dir=ltr does not matter in this case)
17:14:15 <fantasai> Mark: If you put the quote in an embedding level, the problem goes away
17:14:39 <fantasai> Aharon: under Separation, this is displayed as
17:15:06 <behdad> under separation you get the wrong result
17:15:27 <fantasai> yeah. but as Mark points out, you really should be using an embedding level here
17:15:33 <fantasai> even under implicit-only you get the wrong result
17:15:49 <fantasai> read RAED john NASUS DNA today
17:16:02 <fantasai> Aharon: under Isolation this comes out as
17:16:28 <fantasai> read NASUS DNA john RAED today
17:16:50 <fantasai> Aharon puts in the quotes, which behave properly in both cases.
17:17:14 <fantasai> Aharon: As Mark pointed out, what is missing here is dir=rtl around the whole quote.
17:17:27 <fantasai> Aharon: That would be what any guidelines for writing HTML would tell you to do
17:20:40 <fantasai> Aharon: ...
17:20:55 <fantasai> Aharon: We have three levels of text here. It's very common, and should be handled with embeddings anyway
17:21:16 <fantasai> Behdad: If you have Facebook in Farsi with mixed content, it's more common than you thihnk
17:21:31 <fantasai> Roozbeh: What Behdad talks about is my everyday experience
17:21:53 <fantasai> Behdad: I use Facebook in English, write in Farsi, and embed English phrases
17:22:11 <fantasai> Aharon: If this were the only example, I'd say isolation, period. But this is not the only example
17:23:59 <fantasai> Behdad: The bidi spec tries very hard to make bidi depend only on local context
17:24:10 <fantasai> Behdad: But the proposal wants you to keep track of the direction ...
17:24:44 <fantasai> Aharon: The counterpart to the example I just gave is
17:24:48 <fantasai> this
17:24:51 <fantasai> Aharon draws on the board
17:26:45 <fantasai> i spoke to JOHN. <span dir=rtl bdi>SUSAN</span>, MIKE and ollie spoke to him too
17:26:58 <fantasai> Mark: Why would this actually come up? If you mark this by hand, you would never want to do this.
17:27:13 <fantasai> Aharon: In a web app, things get generated by different layers of software.
17:27:49 <fantasai> Aharon: Susan, in our example, is boilerplate (?)
17:28:29 <fantasai> Aharon: In this example, the implicit opposite direction on either side is not part of the same phrase
17:28:34 <fantasai> Aharon: it comes up really broken
17:28:58 <fantasai> Aharon: Does this example convince me? No. It is erroneous usage.
17:29:17 <fantasai> Aharon: The case where it matters, whether we have isolation or separation, is when we have implicit opposite direction text.
17:29:21 <fantasai> Aharon: There are two possibilities.
17:29:33 <fantasai> Aharon: either the text before and after is part of a single phrase
17:29:38 <fantasai> Aharon: or it's not
17:29:47 <fantasai> Aharon: In the first case, isolation works better
17:29:57 <fantasai> Aharon: In the second, separation works better
17:30:45 <fantasai> Roozbeh: My issue is that I can get separation with LRM or RLM today. I can't get isolation with unicode bidi
17:30:50 <fantasai> Aharon: True.
17:31:08 <fantasai> Aharon: But my problem first is, I hate LRM and RLM. They don't reflect the structure of the document.
17:31:23 <fantasai> Aharon: The second problem is, in order to put the right LRM or RLMs in, I need to know what my context is.
17:31:37 <fantasai> Aharon: I could be five levels deep in my software, and have no idea what my context is
17:33:12 <fantasai> Aharon renders the example above
17:33:35 <fantasai> Behdad: The problem is outside the span, actually.
17:33:43 <fantasai> Behdad: The period after JOHN should be forced RTL
17:34:29 <fantasai> Behdad: You're trying to fix a problem with a document that is not written correctly.
17:35:01 <fantasai> Behdad: Even if you remove the span, you get the wrong behavior. So the document is wrong in any case.
17:35:46 <fantasai> Behdad: What I'm trying to say is we have isolation, and you isolate all RTL strings, you get the right behavior.
17:35:55 <roozbeh> Behdad, Aharon's point is that both examples have wrong boilerplates
17:36:23 <behdad> roozbeh: I don't follow.  I thought this was presented to reason for needing separation.  but if the example is WRONG, I don't see the logic
17:36:49 <roozbeh> his point is that it doesn't make a difference in a good clean world.
17:37:14 <fantasai> Mark: The point is that you can do anything you want to do with bidi *if* you know the context.
17:37:27 <fantasai> Mark: The problem here is that you have software stuffing things into other things
17:37:35 <najib-ma> Aharon's point is that he doesn't know if, in his generating program, he has to put LRM or not. Right?
17:37:57 <fantasai> Mark: The use case here is , what do you do if your piece of software doesn't know the context the content is appearing in?
17:38:11 <fantasai> Aharon: If it is done consistently, both isolation and separation will achieve the same result.
17:38:14 <roozbeh> he hates RLM/LRM too
17:39:02 <najib-ma> Everybody hates bidi stuff :-)
17:39:58 <fantasai> Aharon: In any case, the way I view things is that if HTML is being done right, using bdi consistently and properly throughout, it doesn't matter whether you use separation or isolation. You'll get exactly the same result.
17:40:24 <fantasai> Aharon: If you don't use it consistently, you can get strange results and can't predict which method is better.
17:40:39 <fantasai> Aharon: because you don't know whether the surrounding opposite-direction content is one phrase or two
17:41:07 <fantasai> Mark: Isolation is more powerful. You can do Separation with Isolation plus Marks
17:41:54 <fantasai> Behdad: I can think of correct examples where separation causes a problem.
17:42:00 <fantasai> behdad: because it loses the context around the span
17:42:07 <fantasai> behdad works on an example
17:42:48 <fantasai> Aharon: I would like to step away from the examples and show how the two definitions are used today in HTML/CSS
17:43:00 <fantasai> Aharon: Pro for isolation: simpler definition, easier to understand
17:43:18 <fantasai> Aharon: Pro for isolation: bdi attr, if it uses isolation, would work very much like already-existing examples in HTML
17:43:59 <fantasai> Aharon: Pro for isolation: Avoids figuring out what the current embedding level direction is when bidi formatting chars are used
17:44:19 <fantasai> Aharon: Con for isolation: The solution offered for <br> element no longer works.
17:44:27 <fantasai> Topic: <br>
17:44:45 <fantasai> Aharon: <br> is an inline element. As far as bidi is concerned, it acts like a whitespace character.
17:44:49 <fantasai> Aharon: it is not a paragraph break
17:44:54 <fantasai> Aharon: this is a decision that goes way back
17:45:02 <fantasai> Aharon: As far as I understand, the logic behind the decision is like this
17:45:20 <fantasai> Aharon: We want to have easy translation from plaintext to HTML
17:45:35 <fantasai> Mark: In original bidi algorithm, there was paragraph breaks.
17:45:48 <fantasai> Mark: And then sometimes you wanted a hard line break without breaking the paragraph
17:46:02 <fantasai> Mark: The mapping was made to HTMl, since it seemed very like a <p> vs. <br> distinction
17:46:26 <najib-ma>  I'm  not in favor of changing the actual behavior of <br>, but anyway
17:46:26 <fantasai> Aharon: In plaintext there is a line separator character U+2028 LINESEP
17:46:46 <fantasai> Aharon: And we have a paragraph separator character U+2029 PARASEP
17:47:29 <fantasai> Aharon: I don't know if anyone actually uses them. They were added to disambiguate whether you want a paragraph separator, or just a line break
17:47:35 <fantasai> roozbeh: They are used in word processors
17:47:55 <fantasai> Aharon: Then we have U+000A LF -- what do you do with that?
17:48:03 <fantasai> Aharon: Bidi says to treat it as PARASEP
17:48:29 <fantasai> Mark: At the time, word processors needed a distinction between para sep and line break chars, so that's how we wound up with that
17:49:13 <fantasai> Aharon: What happens in HTML, what we have for paragraph separation is not a little-known unicode char, but <p> and <div>
17:49:21 <fantasai> Aharon: people are very much encouraged to use these for indicating pargraphs
17:49:26 <fantasai> Aharon: So we've got <p> and we've got <br>
17:49:41 <fantasai> Aharon: What is <br>? Well, we have a paragraph separator. So <br> will be line separator
17:50:07 <fantasai> Aharon: There are standards that say, if you are translating plaintext to HTML, translate LINESEP to <br> and PARASEP to <p>
17:50:20 <fantasai> Aharon: And newline, I don't think it talks about it.
17:50:22 <fantasai> Mark: It's whitespace
17:50:41 <fantasai> Mark: It says linefeed depends on platform, since semantics are not well-defined
17:51:08 <fantasai> Roozbeh quotes the HTML4 spec 
17:51:28 <fantasai> Aharon: The problem is that authors don't read the specs, and authors don't always use <p>s, they use <br>
17:52:25 <fantasai> Aharon: In plain text, is is very reasonable to use LF as a line break without starting a new paragraph
17:52:31 <fantasai> Aharon: Because in plain text, lines often don't wrap
17:52:42 <fantasai> Aharon: In HTML people don't do that, because text wraps by default
17:53:19 <fantasai> Aharon: For that reason, most uses of <br> in HTML separate paragraphs
17:53:44 <fantasai> Aharon: IE and Webkit treat <br> mostly as a paragraph separator
17:53:48 <fantasai> Aharon: (not quite, but mostly)
17:54:03 <fantasai> Aharon: Webkit, ok, whatever, but IE is still very much the preferred browser in RTL countries
17:54:59 <fantasai> Aharon ...
17:55:12 <fantasai> Aharon: When you view these documents in Firefox, you get very interesting results
17:55:17 <fantasai> Aharon: I wanted to do something about <br>.
17:55:33 <fantasai> Aharon: My original proposal was specifying that <br> should be a paragraph separator.
17:55:48 <fantasai> Aharon: but people said that it's in the spec, and many documents refer to that -- don't fool with it
17:56:29 <fantasai> Najib: As an HTML author, I expect <br> after a word, it behaves as a line break
17:57:08 <fantasai> Najib: If the example is only a list of items with number bullets
17:57:19 <fantasai> Najib: It seems to me that this is not sufficient to do the change
17:57:23 <najib-ma> As an HTML author, I expect  
17:57:24 <fantasai> Aharon: So if I have a numbered list
17:57:25 <najib-ma>   <p>this is a first line <br> and a second line </p>
17:57:26 <najib-ma> to be the same as 
17:57:28 <najib-ma>   <td>this is a first line, and a second line </td> 
17:57:29 <najib-ma> if the table cell is wrapped after the comma.
17:58:12 <najib-ma> <br> should be visually as a line wrap. 
17:58:29 <fantasai> Najib: I expect <br> to behave exactly as a soft line wrap
17:59:02 <fantasai> Mark: There are cases where you want it to behave as a line separator, and others as a paragraph separator.
17:59:40 <fantasai> Aharon: What the proposal currently says is that bdi uses separation, and we can have <br bdi=yes> and <br bdi=no>, and one acts something very close to parasep, and other as linesep
18:00:11 <fantasai> Aharon: My claim is that default should be <br bdi=yes>, since that is more common case, but if you need the other (as in Najib's example), you could up bdi=no
18:00:36 <najib-ma> I have <p> and <div> to separate paragraph
18:00:51 <fantasai> Roozbeh: I think this is really a markup hack
18:01:20 <fantasai> Roozbeh: Treating it as a separator is not something you'd recommend as good markup
18:02:04 <najib-ma> +1
18:02:04 <fantasai> Mark: I think there's definitely a need to distinguish 2 kinds of brs
18:02:20 <fantasai> Mark: We could do it with bdi attribute, we could do it with CSS, we could do it with a different attribute
18:02:44 <fantasai> Mark: I think we're all agreed on the need to have a way to distinguish two different behaviors of <br>
18:02:56 <fantasai> Mark: We can figure out whether it makes sense to conflate the two 
18:04:09 <fantasai> fantasai: How about using <br> inside a <p> as a linesep, and <br> outside <p> as paragraph break
18:04:39 <fantasai> Adil: There are a couple issues I see with this. One is that it uses just CSS
18:04:47 <fantasai> Adil: if the CSS is lost, then you've lost what that <br> should do
18:04:59 <fantasai> Adil: The other is wrt <br> meaning different things inside and outside <p>
18:05:17 <fantasai> Adil: If you're quoting a web page and then displaying that quote, you'd have to parse up the HTML to find out if it's enclosed in a <p> or not
18:05:50 <fantasai> Adil: My feeling is that from a usability perspective, <br> has been used too much now as a paragraph separator and should become a paragraph separator by default
18:05:59 <fantasai> Adil: I would suggest a new tag for line breaks
18:06:16 <behdad> or just an entity?
18:06:27 <behdad> &br; -> U+2028?
18:06:41 <fantasai> Adil: There are cases where people just want to wrap a line, but these are rare cases.
18:06:54 <roozbeh> behdad: U+2028 won't work. It's treated at whitespace in HTML.
18:06:55 <behdad> right
18:06:59 <behdad> roozbeh: ?
18:07:07 <behdad> it doesn't break?  oh right
18:07:13 <roozbeh> yep
18:07:22 <fantasai> Adil: In these cases the person will look the new markup up in a spec and use it
18:07:27 <behdad> sample poetry: http://rira.ir/rira/php/?page=view&mod=classicpoems&obj=poem&id=1
18:07:33 <fantasai> Aharon: If we want to fix this, we have to introduce something new
18:07:49 <fantasai> Aharon: Whatever we add people are not going to use much, because it's new
18:09:04 <najib-ma> I always remove  <br>s inserted by my authoring tool, and replace them with <p>. Because it is the structure of my text 
18:09:07 <fantasai> +1 to not having bidi only in CSS; CSS should be optional for comprehensibility
18:09:32 <fantasai> roozbeh: ..
18:09:56 <fantasai> Aharon: There is no way to create isolation in Unicode
18:09:57 <najib-ma> really? :-)
18:10:00 <fantasai> Aharon: Which is a con
18:10:10 <fantasai> Aharon: I also have a feeling that isolation is harder to implement in browsers.
18:10:28 <fantasai> Aharon: Either harder that it complicates code, or has a runtime penalty
18:10:43 <fantasai> behdad: It's actually much easier. It's like having an image or something
18:11:37 <fantasai> behdad: You already have to support parts of HTML not taking part in bidi algorithm since that's how floats and images are implemented
18:11:49 <ehsanakhgari> right
18:11:56 <fantasai> behdad: you also have to support new paragraph, which is how to implemnt the inside
18:12:17 <fantasai> behdad: But for separation you either need to add the marks, or dive into the depths of your bidi algorithm
18:12:28 <fantasai> roozbeh: How do you deal with copy into plaintext?
18:12:36 <fantasai> behdad: That's already a problem with blocks
18:12:45 <fantasai> behdad: We already know that you can't represent everything in plaintext
18:13:17 <fantasai> fantasai, Mark: You could propose new bidi formatting characters
18:13:36 <fantasai> fantasai: Add new LRI and RLI characters
18:14:09 <fantasai> Mark: We'd have to get buy-in from people who have to support it
18:14:19 <fantasai> Mark: So from MS and Apple and the people who do text processing stuff
18:14:37 <fantasai> Mark: Technically, there are ways to modify the algorithm, but we'd have to make sure people bought into it
18:16:35 <fantasai> Mark: If you wanted it to behave as a neutral, you'd have to see what the neutral would become, and then put marks around it to make it htat
18:16:49 <fantasai> fantasai: and for the inside, jump the embedding up twice
18:17:00 <behdad> U+FFFC OBJECT REPLACEMENT CHARACTER.
18:18:18 <fantasai> roozbeh: Microsoft had some proposals for copy&pasting text out of their systems
18:19:12 <fantasai> Mark: You can't take the isolated fragment of the document and copy it out and behave as the original
18:19:25 <fantasai> Mark: but you could take a fragment that contains the isolated bit and paste it somewhere else
18:19:32 <fantasai> Mark: It would be interesting, but you could do it
18:19:57 <fantasai> Behdad: One more point, I don't agree that separation can be represented in text easily
18:20:08 <fantasai> Behdad: You still need to know whether your context is LTR or RTL
18:20:24 <fantasai> Behdad: it's the same problem, just a little easier because you don't need to run the whole algorithm to figure out which marks to add
18:22:04 <fantasai> Aharon: I propose a break
18:22:13 <fantasai> Aharon: I also what to present what is going on in browsers today.
18:22:17 <fantasai> Aharon: I think break should come first
18:22:31 <fantasai> discussion of break dynamics
18:22:36 <najib-ma> At what time lunch (dinner or me)
18:22:45 <najib-ma> s/or/for/
18:22:47 <fantasai> 10 minute break
18:22:48 <TabAtkins_> Lunch in about 25 minutes
18:22:50 <fantasai> 15 mintues discussion
18:29:09 <roozbeh> the break is more like 5 minutes i think.
18:30:39 <roozbeh> back to meeting
18:31:15 <fantasai> Aharon: Ok, so, yes, it is possible to do isolate with RLM/LRM characters -- you just have to look at the implicit characters on eithe rside
18:31:22 <fantasai> Topic: Existing featuers in browsers
18:31:39 <fantasai> Aharon: So isolation, or something very similar to it, happens when you take an element out of flow
18:31:45 <fantasai> Aharon: It behaves as if the content is not there
18:31:59 <fantasai> Aharon: What's inside is treated as a separate bidi paragraph
18:32:02 <Norbert> Norbert has joined #core
18:32:13 <fantasai> out of flow == CSS floating or abspos 
18:32:23 <fantasai> Aharon: I already mentioned HTML <input> and <textarea>
18:32:32 <fantasai> Aharon: There's also display: inline-block;
18:32:49 <fantasai> Aharon: Which is treated as isolation
18:33:01 <fantasai> Aharon: Separation on the other hand has almost no precedent in browsers
18:33:07 <fantasai> Aharon: The only exception is a block element surrounded by text
18:33:15 <fantasai> Aharon: Where the block element has display: inline
18:33:38 <fantasai> Aharon: Up until recently, the situation was that all browsers treated exactly as an inline element. no bidi separation isolation anything
18:33:45 <fantasai> Aharon: It turns out that was not according to spec
18:33:52 <fantasai> Aharon: recently Firefox fixed that
18:34:32 <fantasai> Aharon: The spec states that if you've got a block element that's display: inline, and it does not have a [dir] attribute, it should nonetheless be treated as if it has a [dir] with its inherited direction
18:35:22 <fantasai> Aharon goes to the whiteboard to explain the rationale
18:35:44 <fantasai> fantasai: the rationale is the same as for putting quotes in an embedding: since it's a block, presumably you want its contents to remain together
18:35:56 <fantasai> Aharon: Example is, suppose I want to render a list inline
18:36:53 <fantasai> Aharon draws an <ol> with numbers, shows how it would render inline
18:37:18 <fantasai> Aharon: If the contents of the list items are RTL, you want to embed each so that the punctuation turns out correctly
18:37:35 <fantasai> Aharon: The goal is to have the contents be isolated from their surrounding contents
18:37:56 <fantasai> Aharon: But the spec didn't realize that the surrounding contents would be affected by the inside contents
18:38:15 <ehsanakhgari> fwiw, the Mozilla fix to display:inline blocks was done in https://bugzilla.mozilla.org/show_bug.cgi?id=503957
18:38:23 <fantasai> Aharon: Currently IE and Opera and Webkit just treat it as inline, so they will be a jumble
18:39:17 <fantasai> Aharon: Firefox recently changed its behavior, but it in fact behaves as separation, not as isolation
18:39:39 <fantasai> Mark: If they did the equivalent of embedding it, that would have the same effect
18:39:44 <fantasai> Aharon: That would not be enough
18:40:13 <ehsanakhgari> here's out reftests: http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bidi/503957-1.html
18:40:16 <ehsanakhgari> http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bidi/503957-1-ref.html
18:40:30 <fantasai> fantasai: In this use case, I would want isolation, not separation.
18:40:50 <fantasai> fantasai: I frequently, for example, write emails where I break in the middle of a sentence to display a blockquote.
18:41:22 <fantasai> roozbeh: Looks like Firefox implements this as embedding.
18:41:44 <ehsanakhgari> roozbeh: that's correct
18:42:22 <roozbeh> break!
18:42:56 <fantasai> fantasai: the patch just adds unicode-bidi: embed to block-level elements and uses the inherited direction
18:43:16 <fantasai> fantasai: I wouldn't want the blockquote to distort the sentence.
19:13:40 <behdad> separation is equivalent to <span bidi=embed><span bidi=embed dir=XXX>
19:34:39 <matial> matial has joined #core
19:35:04 <roozbeh> meeting in a few minutes
19:37:22 <xji> xji has joined #core
19:37:23 <fantasai> thanks, behdad! that's awesome
19:37:43 <Norbert> Norbert has joined #core
19:41:10 <behdad> fantasai, roozbeh: worth testing though.
19:42:24 <behdad> or maybe not.  if there's no character between the spans, the outer one may have no effect.
19:42:45 <Aharon> behdad, could you please give a full example, what is equivalent to what?
19:43:58 <behdad> Aharon: I'm guessing that "<span bdi dir=rtl>SUBTEXT</span>" may be equivalent with "<span bidi=embed><span bidi=embed dir=rtl>SUBTEXT</span></span>".
19:44:05 <behdad> for separation that is.
19:48:45 <Aharon> It works in IE, but not in FF or WebKit, unless there are spaces betwen the inside and outside spans, and IE's behavior is actually not according to Unicode Bidi Algorithm spec.
19:49:52 <najib> najib has joined #core
19:51:12 <behdad> right...
19:53:32 <roozbeh> adil, najib, behdad, and ehsan: please don't leave!
19:53:40 <adil> I'm here
19:53:47 <roozbeh> get on the phone
19:53:49 <ehsan> we're not going anywhere ;)
19:54:23 <roozbeh> meeting starting
19:54:23 <behdad> here
19:54:38 <roozbeh> najib, are you on the phone?
19:55:08 <najib> No, sorry
19:55:22 <roozbeh> najib, please get on the phone
19:55:24 <Aharon> najib, you are going to dial in again?
19:55:49 <najib> if necessary, I can dial in from my mobile
19:56:02 <najib2> najib2 has joined #core
19:56:19 <roozbeh> najib, we can try to reflect what you say on the IRC channel then.
19:56:47 <najib> Yep
19:57:14 <fantasai> Aharon: Behdad made a comment that you can use separation by using a span inside a span
19:57:25 <fantasai> Aharon: That's almost correct but not quite -- it works only in IE, it does not work in FF or WebKit
19:57:39 <fantasai> Aharon: And does not work according to bidi spec
19:58:36 <fantasai> Aharon: Wanted to say about cases where isolation is used today in browsers
19:58:50 <fantasai> Aharon: We said already used by OOF and inline-block and form elements
19:59:13 <fantasai> Aharon: As far as I'm concerned, it's neither necessary nor even desireable to be able to control the behavior of all of these through bdi
19:59:20 <fantasai> Aharon: Let's say bdi does isolation
19:59:35 <fantasai> Aharon: I don't think it would make sense to make what float-left/float-right do subject to bdi
20:00:00 <fantasai> Aharon: And the same for display: inline-block
20:00:09 <fantasai> fantasai: I think that would be contrary to the CSS specs
20:00:48 <fantasai> Aharon: So nothing we discuss here for bdi will be taken as pertaining to those
20:01:01 <fantasai> roozbeh: If we specify isolation, things like that could point to isolation spec
20:01:14 <fantasai> Topic: bdi defaults
20:01:31 <fantasai> Aharon: Wanted to talk about default values
20:01:42 <fantasai> Aharon: Want to make a statement. 
20:03:30 <fantasai> Aharon: I think if we wanted to redesign HTML, we would make dir attribute imply bdi
20:03:35 <fantasai> Aharon: but we're not going to be changing that anyway
20:03:48 <fantasai> Aharon: When it comes to dir=auto, I suggest making bdi the default for dir=auto
20:04:32 <fantasai> roozbeh: Nothing leaks from inside to outside, right?
20:05:03 <fantasai> mark: Right, nothing leaks from outside to inside or inside to outside. The only question is what does it look like from the outside
20:05:38 <fantasai> Aharon reads through other items on list:
20:05:48 <fantasai> <a>, <br>, block elements with inline display, inline-block
20:06:18 <fantasai> Aharon: For dir=auto, it's obvious we want to have inside be a separate entity
20:07:00 <fantasai> Aharon: For <a>, if we were starting from scratch, of course we would want bdi by default. But since it is not currently, changing behavior can break existing pages
20:07:05 <fantasai> Aharon shows an example from his email
20:07:53 <fantasai> Aharon: You can have this example and it would work today. But if we change to use bdi, it will behave differently.
20:08:24 <najib> q+
20:09:03 <fantasai> Mark: We should not forget also that it will take years for browsers to transition.
20:09:33 <fantasai> Mark: We have to be very careful about backwards compatibility
20:09:49 <najib> Its contents, the link text, must remain together.
20:10:29 <fantasai> Mark: So you're proposing that we not make bdi a default except for dir=auto, and <br> we need to figure out what we want to do
20:11:55 <fantasai> RESOLVED: Wrt HTML: bdi default for dir=auto, not for <a>, <br> behavior TBD
20:12:56 <ehsan> +1
20:13:40 <fantasai> fantasai: I suggest isolation as the best option for block-level elements with inline display
20:14:39 <behdad> fantasai: that's the same as display: block-inline also btw.
20:14:45 <fantasai> fantasai: inline-block is out-of-scope for HTML, already defined
20:15:15 <behdad> right
20:16:46 <fantasai> RESOLVED: bdi will be ignored by all elements that are not display: inline ( or run-in as inline)
20:17:04 <adil> najib: look at https://docs.google.com/document/edit?id=1Wv0ruqzJfLEd2Ebpk46YaG2ZkS8dmToy1Cl4kNm46iw&hl=en#
20:18:48 <najib> najib has joined #core
20:19:10 <najib> http://www.w3c.org.ma/Tests/Bidi-Fev-2010/bidiLinkText.html
20:20:19 <fantasai> The group notes that any best-practices documents would need to be updated once any of these proposals go into effect.
20:21:54 <ehsan> I also think that we need to specify what should happen with OOF elements explicitly
20:22:20 <fantasai> najib, unicode-bidi: embed
20:26:55 <fantasai> RESOLVED: HTML block-level elements with display: inline will be bdi by default
20:27:15 <fantasai> Aharon: I would like to understand why they should be isolation instead of separation by default
20:27:45 <fantasai> Aharon: When they were blocks, what you had in between was full paragraph breaks
20:28:08 <fantasai> Aharon: And separation is much closer to full paragraph breaks than isolation
20:28:16 <najib> Agree with block-level elements with display: inline will be bdi by default
20:28:47 <fantasai> Aharon: But whatever it is they do, they will be subject to bdi, so you can say bdi=no and they will behave as regular inline elements
20:30:03 <fantasai> fantasai: So the point is, we will discuss the defaults for various HTML elements
20:30:22 <fantasai> fantasai: But the basic idea is that if the element is rendered as a CSS non-replaced inline element, then it will be subject to bdi elements
20:31:16 <fantasai> RESOLED: bdi has an effect on all and only elements that are rendered as non-replaced inline boxes
20:31:24 <fantasai> s/RESOLED/RESOLVED/
20:34:34 <fantasai> Aharon: Ok, so we should start discussing what exactly we want to do with bdi and separation and isolation
20:34:53 <fantasai> Aharon writes on the whiteboard
20:35:14 <fantasai> Aharon: Options are:
20:35:29 <fantasai> roozbeh: Let's talk just about bdi and discuss <br> later
20:35:39 <fantasai> everyone in the room strongly agrees with this suggestion
20:35:42 <fantasai> 1. bdi uses separation
20:35:46 <fantasai> 2. bdi uses isolation
20:35:50 <fantasai> 3. bdi allows choosing
20:36:41 <fantasai>   a) none b) separate c) isolate d) paragraph break
20:37:12 <fantasai> Aharon: So d splits into two UBA paragraphs -- has no effect on line breaks
20:37:51 <fantasai> roozbeh: The UBA algorithm isn't very happy with having inline paragraph breaks I think
20:38:51 <najib> najib has joined #core
20:39:28 <fantasai> fantasai: So what that would do is pop all embedding levels and overrides, insert a mark that corresponds to the base paragraph direction, and push back all of the embeddings and overrides
20:39:34 <fantasai> general consensus: yuk
20:39:55 <fantasai> Mark: I don't think we have a good use case or 4, and I think it would be more problematic to deal with. So maybe we should cross that off for now
20:40:04 <fantasai> Aharon crosses off the paragraph break option
20:40:23 <fantasai> 3. bdi allows choosing separate or isolate
20:40:38 <fantasai> Aharon: Are authors going to understand the difference?
20:40:59 <fantasai> behdad: I don't think we want to expose authors to the different options
20:41:14 <fantasai> behdad: Chances are they'll choose the wrong option.
20:41:31 <fantasai> roozbeh: Browser writers would get a headache too
20:41:33 <ehsan> fantasai: it was actually me ;)
20:42:40 <fantasai> Mark: Let's put aside 3 for now then
20:42:47 <fantasai> Topic: <br>
20:43:00 <fantasai> Aharon: Assuming bdi does isolation...
20:43:24 <fantasai> 1. Add <wrap> element which always acts as whitespace
20:43:35 <fantasai> for bidi purposes
20:44:16 <fantasai> and <br> spec changes to UBA paragraph break
20:44:41 <fantasai> Aharon: But if around the <br> you have an embedding, the UBA paragraph break will break that
20:44:54 <fantasai> (above 2 lines by Mark)
20:46:25 <fantasai> Aharon: You'd split the embedding run, and then you'd have to do what fantasai said -- close all HTML and CSS embeddings and reopen (just the non-Unicode-character-triggered) embedding levels
20:47:40 <fantasai> Aharon: Existing behavior is, afaict -- IE does what we just stated: it pops all the embedding levels, then pushes all the ones that came from HTML and CSS (but not the ones from Unicode characters)
20:48:36 <fantasai> Aharon: this is what you'd have to do for a paragraph separation definition
20:48:58 <fantasai> Aharon: Webkit, as of a year ago, would terminate all the embedding levels, but did not load them back up after the <br>
20:49:23 <fantasai> Aharon: So for <br> inside <span dir=rtl>, before would be RTL, and after the <br> would be LTR
20:49:34 <fantasai> Aharon: Opera and Firefox treat <br> as LINESEP
20:50:10 <fantasai> 1. add <wrap> element whcih acts as linesep for bidi
20:50:24 <fantasai>  a. Change <br> spec to UBA paragraph break
20:51:10 <fantasai>   b. Change <br> to separation (i.e. insert mark based on current embedding level)
20:53:21 <fantasai> ...
20:53:38 <fantasai> Adil: The average web developer, when seeing a <br>, probably thinks of <br> as a paragraph break
20:54:36 <fantasai> fantasai: For an author, they're probably not thinking of embedding levels. I doubt separation and paragraph break will be distinct in their minds
20:55:37 <najib> Usual bidi considerations are already confusing authors. 
20:55:38 <fantasai> 2. add a new attribute
20:56:07 <fantasai> Mark, roozbeh: Attributes are much easier to introduce
20:56:19 <fantasai> Mark, roozbeh: It's not a political consideration, it's a technical one
20:56:57 <fantasai> Aharon: We could add a new attribute just for br
20:57:16 <fantasai> Mark, Tab: We often add attributes specific to a particular element
20:57:25 <fantasai> behdad: Attribute may be useful in <pre> as well
20:57:51 <fantasai> roozbeh: You would set the same attribute on the <pre>, and that would apply to the line breaks inside the pre
20:59:10 <fantasai> Ehsan?: Having it affect both <br> and line breaks would be best
20:59:47 <fantasai> s/breaks/breaks inside the <pre>/
20:59:53 <ehsan> right
21:00:09 <fantasai> 2. Add a new attribute that affects <br> and newlines (and <br>s) in <pre>
21:01:05 <fantasai> Aharon: Names?
21:01:09 <fantasai> fantasai: bidi-break
21:01:19 <ehsan> +1 for bidi-break
21:01:19 <fantasai> roozbeh: I think we want three options here.
21:01:29 <najib> go for bidi-break
21:02:24 <fantasai> fantasai: I think the default should be separation, and you should have the option to make it behave as linesep
21:02:40 <fantasai> roozbeh: Have the default be "old behavior, do whatever"
21:02:49 <ehsan> I don't agree with roozbeh at all
21:04:41 <fantasai> fantasai: I think the separation behavior is the best compromise and will break the least number of documents.
21:05:05 <fantasai> fantasai: It doesn't completely break embeddings -- chances are if you have one, you meant it nott as a paragraph break
21:05:19 <fantasai> fantasai: And for people dealing with only one embedding level, it creates the same break as a paragraph break
21:05:34 <fantasai> fantasai: I think it will break the least number of documents and give us the best default behavior
21:08:20 <fantasai> some discussion of separation vs. parasep
21:08:40 <fantasai> roozbeh: Say you're using <pre> to paste in content from a plaintext document
21:09:18 <fantasai> Aharon writes block-in-inline case: hello <div/> there
21:09:27 <fantasai> Aharon: Possibilities for breaks
21:09:36 <fantasai>   1. Use full paragraph break for <br> and block-in-inline
21:09:42 <fantasai>   2. Use separation for <br> and block-in-inline
21:09:58 <fantasai>    which gives problem for plaintext pasted into <pre>
21:10:08 <fantasai> 3. <br> does one thing, embedded blocks do another
21:10:25 <fantasai> Adil: One issue I have here is if you have a rich text editor either inside an email client or web page
21:10:41 <fantasai> Adil: Most of them will be inserting <br>s whenever the user types a carriage return
21:10:57 <fantasai> Adil: Most mail clients send a corresponding plaintext version
21:11:18 <fantasai> Adil: Most people expect <br> and CRLF to correspond
21:12:00 <fantasai> Aharon: If we're defining <br> as separation, but translating to plaintext, then I would say it would not get translated to carriage return with RLM/LRM marks, but just carriage return by itself
21:12:12 <fantasai> Aharon: So the plaintext and HTML are not equivalent
21:12:26 <fantasai> Aharon: The difference is not a huge one -- it's only different if you've got unclosed embeddings before teh break
21:12:53 <fantasai> Adil: So you'll only get LRM/RLM inserted if there happens to be more complex situation with embeddings
21:13:14 <fantasai> Aharon: No, you would always get <br> to LF
21:14:23 <fantasai> fantasai: So you'd get different bidi behavior in the plaintext and HTML equivalents
21:14:37 <fantasai> Aharon: So that's an argument for using full UBA break
21:15:04 <fantasai> Adil: This type of thing is the most common case, where people are writing simple messages like this
21:15:25 <fantasai> Adil: This kind of content exists all over. What happens when a new browser displays that?
21:16:11 <fantasai> Aharon: I don't have a problem with making <br> as a full paragraph break
21:16:24 <fantasai> roozbeh: Behdad, how difficult would that be?
21:17:16 <fantasai> fantasai: It really depends on the layout engine. In Gecko <p> breaks the layout object, whereas <br> just ends the line
21:17:47 <fantasai> behdad: You could set the <br> to embedding level zero or one -- that does the job
21:18:06 <fantasai> Aharon: That does separation. It won't do a full UBA paragraph break, closing all open embeddings
21:18:20 <fantasai> Aharon: Ok, let's put that off and go back a bit
21:18:38 <fantasai> Aharon: So we're saying we want to add a new attribute that affects <br> and newlines and <br>s inside <pre>
21:18:49 <adil> +1 for new attribute for br
21:18:52 <fantasai> Aharon: It's a binary attribute, and by default it's on, which means either paragraph break or separation
21:18:59 <fantasai> Aharon: off treats the breaks as whitespace
21:19:24 <fantasai> Aharon: Let's give it a temporary name
21:19:37 <fantasai> fantasai: bidi-break
21:20:02 <najib> +1
21:20:21 <fantasai> Tab: I would like the boolean attributes to work like HTML boolean attributes
21:20:29 <fantasai> Tab: so it can be minimized
21:21:27 <fantasai> Tab: so if it's present, it's on
21:21:40 <adil> br bidi-break=para|line|separate
21:23:17 <fantasai> Tab: you could also say there's an attribute with three names, and have none of them be the attr name
21:23:26 <TabAtkins_> s/names/values/
21:23:36 <fantasai> Mark: bidi=break|no-break
21:24:17 <fantasai> Behdad: So are you saying that the use cases for this new attr are distinct from the use cases for unicode-bidi and bdi?
21:25:38 <adil> <br bidi="break""> ?
21:25:45 <fantasai> Behdad: I suggest the HTML bidi attribute should map 1-1 to CSS unicode-bidi
21:26:09 <fantasai> Ehsan: Remember also that this will be used on <pre>. I don't think <pre bidi=break> is very meaningful
21:26:36 <fantasai> Tab: bidi-break=brea|no-break
21:26:50 <adil> <br bidi-break="break|no-break""> ?
21:27:31 <najib> or s/<br bidi-break="break|no-break"">/<br bidi="break|no-break"">/
21:28:20 <ehsan> najib: actually, I think the consensus is <element bidi-break="break|no-break">
21:28:48 <najib> Ok, but too much "break"
21:29:08 <fantasai> RESOLVED: Add new attribute for <br> and <pre> elements, with <pre>'s value propagated to descendant <br> and newlines
21:29:24 <fantasai> that determines whether there is a bidi break or to treat as linesep
21:29:55 <fantasai> Tentative syntax: bidi-break="break|no-break"
21:30:30 <najib> this means bidi-break=yes|no
21:30:42 <fantasai> Ehsan?: Not sure about the dash.
21:31:17 <fantasai> existing attributes with dash: http-equiv, accept-charset
21:31:21 <fantasai> CSS version will have dashes for sure
21:31:45 <fantasai> Behdad: Why not be able to set this on <body>, or whatever?
21:31:57 <ehsan> fantasai: s/Behdad/Ehsan/ ;)
21:31:59 <fantasai> Behdad: Then have it inherit
21:32:41 <roozbeh> 10 minutes break
21:32:42 <fantasai> 10 minute break
21:33:01 <TabAtkins_> <br dur=10m>
21:33:51 <behdad> break
21:44:38 <fantasai> Aharon summarizes
21:44:49 <behdad> "unicode-bidi: neutral"?
21:44:56 <fantasai> * bdi will do isolation (not separation). Rename it to bidiisolate?
21:45:06 <adil> how about <c>
21:45:14 <behdad> how about <bdi> :P
21:45:17 <fantasai> roozbeh: I am going to be using this a *lot*. And for us we are squeezing bytes here. Even one character less makes a difference
21:45:19 <behdad> goes with <bdo> nicely
21:45:47 <fantasai> RESOLVED: bdi does isolation, not separation
21:45:59 <roozbeh> unicode-bidi: isolate
21:46:05 <behdad> right
21:46:10 <behdad> roozbeh: so then bidi="isolate"?
21:46:28 <fantasai> Behdad: What about CSS?
21:46:33 <fantasai> fantasai: unicode-bidi: isolate
21:46:33 <roozbeh> Mark: ubi
21:46:59 <adil> that is a building parts shop in germany
21:47:24 <roozbeh> there's a ubisoft company too.
21:47:25 <fantasai> RESOLVED: CSS value unicode-bidi: isolate does isolation
21:48:40 <fantasai>  * inside the element is independent UBA paragraph
21:48:58 <fantasai>  * from outside looks like U+FFFC Object Replacement Character
21:50:03 <adil> but we can combine it with dir so <span dir=rtl ubi=ubii>
21:50:03 <fantasai> Mark: ubi is easy to understand as acronym for "unicode-bidi: isolate"
21:50:43 <adil> +1 ubi
21:52:37 <fantasai> Behdad: The common case isn't going to be this attribute, dir="auto" is the common case
21:53:00 <fantasai> Aharon: So rename to bidi-isolate=bidi-isolate
21:53:07 <fantasai> RESOLVED: bidi-isolate=bidi-isolate
21:53:19 <fantasai> Adil: You could have both
21:56:42 <fantasai> discussion of dir="auto" and 'direction: auto'
21:57:12 <fantasai> fantasai: We don't want 'direction: auto' in CSS. dir="auto" should resolve to either left or right
21:57:42 <fantasai> fantasai: This is so that we can have :ltr and :rtl selectors to style based on the direction as specified/defined in CSS
21:57:52 <fantasai> fantasai: we can't select on CSS property values -- it has to be resolved in the markup
21:58:04 <fantasai> everyone agrees this is a good idea
21:58:26 <fantasai> roozbeh: I read CSS 'direction', but never write to it. It's useful to have it resolved to either left or right
21:59:55 <fantasai> Discussion of bidi-break
22:00:32 <ehsan> <pre><span bidi-break="bidi-break">\n</span></pre>
22:00:34 <fantasai> Everyone agrees to add dash to bidi-break to be consistent with bidi-isolate
22:03:10 <fantasai> Discussion of what newlines are affected -- whether they need to be inside <pre>?
22:03:22 <fantasai> CSS white-space can make any element's LF characters visible as breaks
22:04:28 <fantasai> Summary: Add bidi-break="no-break"|"bidi-break"|"", where bidi-break and empty string are equivalent.
22:04:32 <fantasai> Default is bidi-break
22:04:42 <najib> najib has joined #core
22:04:52 <fantasai> Effect on <br> and newlines is to do a UBA paragraph break
22:05:46 <fantasai> CSS equivalent is new property, unicode-bidi-break: break|no-break
22:06:05 <fantasai> Mark: Should include 'unicode' so people don't wonder when they need to include "unicode" in front of "bidi"
22:06:22 <TabAtkins_> Semantically, bidi-break only has meaning for significant newlines (<br>, newlines and <br> inside <pre>), but it can have a visual effect anywhere newlines are non-collapsed by CSS.
22:07:59 <fantasai> TabAtkins_: ????
22:08:32 <fantasai> TabAtkins_: the effect of bidi is always purely visual
22:08:57 <TabAtkins_> fantasai: Hm, kk.
22:09:10 <najib> najib has joined #core
22:09:12 <fantasai> TabAtkins_: unlike most visual things, there's no other right alternative
22:09:18 <fantasai> s/right/not-wrong/
22:09:45 <fantasai> roozbeh: Actually, I think I might use bidi-isolate a lot more often, together with dir="ltr|rtl", in order to prevent leaking
22:10:06 <fantasai> Aharon: So we go back to ubi
22:10:34 <fantasai> behdad asks for examples
22:10:53 <fantasai> Aharon: So in an Arabic UI I may have English labels. I know the direction already
22:11:22 <fantasai> behdad: I know it's useful sometimes, but it's not as common
22:11:38 <fantasai> adil: I can see using it a lot, e.g. hashtags and @tags in twitter
22:11:48 <fantasai> adil: Even in those rare cases, it will get used a lot a lot
22:11:52 <fantasai> (sic)
22:12:08 <fantasai> Aharon: So we keep dashes in bidi-break due to CSS
22:12:28 <fantasai> Aharon: All the names are tentative anyway, HTMLWG and CSSWG can play with them later
22:12:36 <adil> @fantasai - you really did not have to quote me that literally
22:13:27 <fantasai> :)
22:13:53 <adil> i/me wonders of there is a CSS style for that
22:14:51 <fantasai> Aharon: So ubi="ubi"|""... what should the "no" value be called?
22:14:59 <fantasai> fantasai: When would you ever want to turn it off?
22:15:31 <fantasai> fantasai: It's only ever on by default for dir="auto" and I can't imagine you'd ever want to turn it off for that.
22:15:41 <behdad> we dropped off.  joining back
22:16:11 <ehsan> (we're back on)
22:16:14 <fantasai> it does not inherit, so there's no need to turn off
22:16:26 <fantasai> Tab: We can add a value for off later if we ever find a use case. Right now it doesn't seem needed.
22:20:00 <fantasai> [ubi] { unicode-bidi: isolate }
22:20:20 <fantasai> [dir=auto], [ubi] { unicode-bidi: isolate; }
22:20:43 <behdad> how about this:
22:20:55 <Norbert> Norbert has joined #core
22:21:17 <behdad> <span dir=auto>%s</span>: <span dir=auto>%s</span>
22:23:25 <TabAtkins_> TXETCIBARA :EMANCIBARA  <--?
22:23:48 <TabAtkins_> EMANCIBARA: english text  <--?
22:24:52 <Aharon> <span dir=auto>%s: <span dir=auto>%s</span></span>
22:25:30 <TabAtkins_> Aharon's would do "englishtext :EMANCIBARA", right?
22:25:36 <Aharon> correct
22:25:51 <fantasai> fantasai: That makes way way more sense
22:26:23 <fantasai> fantasai: Behdad's example, the name and message would swap places depending on whether the speaker's message starts with an English phrase or an Arabic one.
22:26:34 <fantasai> fantasai: This way it only depends on the speaker's name, so it doesn't swap around like crazy
22:26:55 <fantasai> Aharon: If you wanted the direction determined by the message isntead of the speaker, then wrap the speaker's name in dir=auto instead.
22:29:29 <fantasai> RESOLVED: Add ubi=off
22:34:49 <fantasai> Topic: default for <br>
22:35:29 <adil> not the first time that an i.e. bug defined the standard
22:35:50 <najib> najib has joined #core
22:35:55 <fantasai> Behdad: I don't care as much what browsers do, but what's expected by web developers and web authors
22:36:09 <fantasai> behdad: And I think that should be reflected in the proposal that we will make
22:36:27 <behdad> fantasai: s/behdad/ehsan/gi :)
22:36:42 <fantasai> ehsan: I think what current web authors expect is <br> to behave as a paragraph separator
22:37:48 <roozbeh> Adil, not necessarily an IE bug.
22:38:08 <TabAtkins_> [ubi=""],[ubi="ubi"], [dir="auto"]:not([ubi="off"]) { unicode-bidi: isolate; }
22:38:25 <adil> @roozbeh: I know - just being flippant
22:38:37 <fantasai> Behdad: Also wanted to consider newline characters in textareas
22:39:13 <ehsan> me again!
22:39:17 <fantasai> gah
22:39:22 <fantasai> s/behdad/ehsan/
22:39:54 <behdad> fantasai: I shut up until further notice
22:39:54 <fantasai> ehsan: and script dialog text
22:40:13 <fantasai> Aharon: reads from popsal text
22:41:06 <fantasai> Aharon:We've changed the bit about <pre> from section 3.2 to say that they are treated as paragraph breaks or line separators depending on new attribute bidi-break
22:41:16 <fantasai> Aharon: Question arises, should the same hold true for textarea
22:41:45 <fantasai> Aharon: Why did we loop together <br> and LF?
22:41:53 <fantasai> Tab: Because they're equivalent
22:43:55 <fantasai> CSS2.1: "User agents that support bidirectional text must apply the Unicode bidirectional algorithm to every sequence of inline boxes uninterrupted by a forced line break or block boundary."
22:45:09 <fantasai> roozbeh: Copypaste processing might convert between characters and <br>
22:45:33 <fantasai> Mark: What's roozbeh's saying is that if you have a bunch of some text into <pre>, LINESEP characters should behave as they did outside <pre>
22:45:57 <fantasai> Mark: He's also saying that LINESEP might be replaced by LF, and expect them to behave the same..?
22:46:12 <fantasai> Mark: I don't see a good use case for controlling this inside <pre>
22:46:29 <fantasai> roozbeh: So you're saying that inside a <pre>, all newlines just work as paragraph separators
22:47:39 <fantasai> Aharon removes text about bidi-break affecting newlines
22:47:58 <fantasai> RESOLVED: bidi-break only affects descendant <br> elements, not newlines
22:48:33 <fantasai> RESOLVED: all non-collapsed newlines, e.g. in <pre> and <textarea>, are treated as UBA paragraph breaks
22:48:48 <fantasai> where newlines != linesep character
22:49:36 <fantasai> Thus to get a UBA line break, you need to use either LINESEP  or <br bidi-break>
22:49:39 <fantasai> er
22:49:42 <fantasai> <br no-break>
22:49:49 <fantasai> <br bidi-break=no-break>
22:50:58 <fantasai> roozbeh: HTML4 9.1
22:51:27 <roozbeh> "Note that although &#x2028; and &#x2029; are defined in [ISO10646] to unambiguously separate lines and paragraphs, respectively, these do not constitute line breaks in HTML, nor does this specification include them in the more general category of white space characters."
22:52:34 <fantasai> RESOLVED: HTML5 and CSS2.1 should clarify that LINESEP and PARASEP in <pre>/white-space:pre should behave as specified for plaintext, i.e. cause a line break and affect bidi as specced in UAX9
22:52:56 <fantasai> (also for <textarea>
22:52:57 <fantasai> )
22:53:49 <fantasai> fantasai: So, on a related note, we're defining bidi-break in a way that makes the minimized value the same as the default behavior. Which is not useful
22:54:18 <fantasai> fantasai: I suggest bidi-break=soft|hard
22:54:51 <ehsan> s/is/as/
22:55:03 <fantasai> ?
22:55:19 <ehsan> nevermind, I was pointing out a typo in the meeting notes
22:55:32 <ehsan> (it was corrected)
22:55:57 <fantasai> RESOLVED: bidi-break=soft|hard, default is hard. Hard treats <br> as B, soft treats <br> as WS
22:59:21 <behdad> roozbeh: we have to leave soon
23:06:44 <adil> suggestion - I want to contribute to the discussion on 2.4 - but it is getting late for me now can we add that to tomorrow morning's agenda?
23:09:26 <roozbeh> disconnecting the phone
23:10:20 <fantasai> Topic: 3.4 - Script dialog text should be displayed in the page's direction
23:12:06 <fantasai> Aharon: In one of the browsers, either webkit or ff (forget which), it's always LTR.
23:12:15 <fantasai> Aharon: In the other it depends on the browser's UI direction
23:12:54 <fantasai> Aharon: the result of the fact that there's no interop is that one doesn't know what the heck to do
23:13:20 <fantasai> Aharon: Specifying the direction on script dialog text is very difficult, because it has to be done with RLE/LRE characters
23:13:26 <ehsan> fantasai: iirc in Firefox it now depends on the UI direction
23:13:28 <fantasai> Aharon: And it has to be done on each paragraph independently
23:13:50 <ehsan> right
23:14:15 <fantasai> Aharon: Ideally, I would like to be able to say, at the time of the alert whether i want ltr or rtl
23:14:25 <fantasai> Aharon: But it has nothing to do with HTML or CSS specs
23:14:57 <fantasai> fantasai: We do have contacts in the ECMAScript standards group
23:15:08 <fantasai> Aharon: So we can recommend that.
23:15:17 <fantasai> Aharon: The problem remains when it's not explicitly set, what should the baseline be
23:15:39 <fantasai> Aharon: There is a related problem--
23:16:38 <fantasai> Aharon: It's quite clear that if you have an LTR page, you never want to have to explicitly specify LRE/PDF around your script dialog text.
23:16:46 <fantasai> Aharon: Why would you want to do that in the first place?
23:16:59 <fantasai> Aharon: Currently, there is at least one browser where the script direction depends on the UI direction
23:17:13 <fantasai> Aharon: So if the page is LTR but the browser is RTL, then it's garbled
23:17:46 <fantasai> Aharon: Suppose you're clued in enough to be aware of the problem. You put LRE/PDF.
23:18:02 <fantasai> Aharon: On WinXP, unless RTL script support is explicitly enabled, you will see boxes
23:18:17 <fantasai> Aharon reads from proposal
23:19:58 <fantasai> Aharon: Richard has a test for this, testing for a script running off the context of a specific element, based on direction of that element
23:20:14 <fantasai> roozbeh: You might want this if you have different modules inside a page
23:20:38 <fantasai> Aharon: So you have a general page, e.g. in English, and then you have part of the page e.g. in Arabic
23:20:50 <fantasai> roozbeh: Yeah. Say this module is only available in Arabic
23:21:05 <fantasai> Mati: User might be mashing up modules from different pieces
23:21:12 <fantasai> Aharon: Those are done with frames
23:21:16 <fantasai> roozbeh: Not necessarily
23:21:32 <fantasai> Aharon: Ok, I see the rationale.
23:21:39 <fantasai> Aharon: On the other hand, there are problems.
23:21:58 <fantasai> Aharon: Say I have a function that checks for the syntax of phone numbers
23:22:10 <fantasai> Aharon: It pops up an error message
23:22:23 <fantasai> Aharon: I didn't bother with i18n, so message is in English
23:22:58 <fantasai> Aharon: It can't specify direction via JS because not supported, can't use characters because WinXp screws up
23:23:18 <fantasai> Aharon: So it gets direction from style.direction
23:24:28 <fantasai> roozbeh: This is what we want, because it's powerful. The places where it doesn't work are mostly those which are broken anyway
23:25:10 <fantasai> Aharon: not sure it belongs in HTMl5
23:25:27 <fantasai> Tab, fantasai: Should still discuss it there anyway. If it doesn't belong, can be redirected from there.
23:25:31 <fantasai> ...
23:26:00 <fantasai> Aharon: One objection is there are rtl sites out there, big ones, with no ltr equivalent,
23:26:06 <fantasai> Aharon: that do not use dir=rtl on the body
23:26:53 <fantasai> Aharon: I'm guessing they don't do it further up, is because browsers used to do weird things e.g. with float in IE in rtl context
23:27:12 <fantasai> Aharon: So the suggestion to use page direction doesn't really work for them, although local direction would work
23:27:18 <fantasai> Aharon: Another issue that has been raised
23:28:04 <fantasai> Aharon: is that I've got a function, I use the same function in ltr and rtl pages
23:28:14 <fantasai> Aharon: I don't what to check which one is it in order to wrap or not to wrap
23:28:21 <fantasai> Aharon: So what do we want? 2 possibilities
23:28:33 <fantasai> Aharon: One is always default to LTR. 
23:28:45 <fantasai> roozbeh: So always ltr, even if page, and UI, everything is rtl
23:28:51 <fantasai> Aharon: The other proposal is to make it auto
23:29:02 <fantasai> Aharon: It would be nice if that were just the default, but right now there is no way to specify
23:29:12 <fantasai> Aharon: because there is no direciton parameter to alert and direction
23:29:21 <fantasai> roozbeh: Auto would work, but depends on how we do auto
23:29:35 <fantasai> Aharon: That ties into dir=auto, and we plan to discuss that tomorrow.
23:29:42 <fantasai> Aharon: Let's say dir=auto is smart enough
23:29:53 <fantasai> Aharon: and it subtracts out embeddings, etc.
23:30:08 <fantasai> Aharon: Or can be more advanced, and say the following
23:30:32 <fantasai> Aharon: That you take the text, you break it up into paragraphs...
23:30:47 <fantasai> roozbeh: Just treat it as plaintext and use the UBA heuristic.
23:31:24 <fantasai> Aharon: If I've got around a particular paragraph you have RLE/PDF or LTR/PDF, and if that happens to be the default around the surrounding environment, then strip it
23:32:03 <fantasai> roozbeh: That's a box issue. The browser can deal with that if it's got a box issue on the OS.
23:32:27 <fantasai> Aharon: What's wrong with using auto-detection? Sometimes you know what the direction is, and you don't want estimation to get it wrong possibly
23:32:54 <fantasai> roozbeh: That brings us back to auto-direction issue. You're assuming that auto-direction does a good statistical analysis.
23:33:10 <fantasai> roozbeh: If the heuristic is very simplistic, then you can just stick an RLM or LRM in front
23:33:21 <fantasai> Aharon: but that gets displayed as boxes too
23:34:17 <fantasai> Norbert: What if you want to insert text from the user? Then you don't know the effect
23:35:58 <fantasai> Norbert goes up to the board to list options
23:36:02 <fantasai> 1. baseline is LTR
23:36:13 <fantasai> 2. Use BODY direction
23:36:22 <fantasai> 3. Use local element direction
23:36:38 <fantasai> s/local/scope
23:36:51 <fantasai> 4. Automatic direction (estimated or UBA)
23:38:22 <fantasai> RESOLVED: Approach EcmaScript people about having a direction parameter to alert functions
23:40:10 <fantasai> s/alert/alert-confirm-prompt/
23:40:44 <fantasai> pros and cons
23:41:05 <fantasai> 1 crossed off -- not i18n-friendly
23:41:54 <fantasai> Aharon: 2. BODY direction doesn't do with widgets, and doesn't deal with rtl-sites not using global dir
23:42:12 <fantasai> Aharon: 3. non-internationalized message has to jump through hoops to come out right
23:42:30 <fantasai> Aharon: 4. Only objection is that if you know the direction, you can't express it
23:42:57 <fantasai> roozbeh: Last one works or doesn't depending on how you detect the direction
23:43:18 <fantasai> roozbeh: One option is statistical analysis of the whole message
23:43:24 <fantasai> roozbeh: Another option is statistical per paragraph
23:43:39 <fantasai> roozbeh: or you can do UBA (first-strong) per paragraph
23:43:59 <fantasai> roozbeh: I prefer UBA, because I can control it
23:45:07 <fantasai> Aharon, Mati: Can control with other options too, e.g. by encasing paragraph in embedding
23:45:38 <fantasai> roozbeh: three is definitely wrong. two is a hack
23:46:15 <fantasai> Aharon: So do we do per-paragraph, or the whole thing?
23:46:24 <fantasai> Aharon: and do we change the alignment based on the resulting direction?
23:47:09 <fantasai> Aharon: note that the rest of the dialog box will be dependent on the UI
23:50:47 <fantasai> Mati: The auto algorithm we choose for alerts might be different from dir=auto
23:52:46 <fantasai> Aharon explains, conclusion that per-paragraph seems better
23:56:01 <xji> xji has joined #core
23:56:37 <Norbert> discussion on alignment
23:56:39 <fantasai> [unminuted discussion about alignment]
23:58:15 <fantasai> RESOLVED: Alignment out-of-scope, UA-determined
23:58:27 <fantasai> RESOLVED: Alerts should use per-paragraph automatic