Return to Video

Social Machines X Reaction

  • 73:14 - 73:44
    Engineering (VisualEditor)
    Against the Odds
  • 73:49 - 73:53
    Alright
  • 73:53 - 73:56
    Hello, everybody. I'm Trevor Pascal.
  • 73:56 - 74:04
    This is Roan Kattouw and Ed Sanders,
    we work at the Wikimedia Foundation, specifically the VisualEditor
  • 74:04 - 74:10
    and today we want to talk to you a little bit about
    some of the challenges that we have to deal with
  • 74:10 - 74:13
    for the past couple of years
  • 74:13 - 74:19
    and how working on VisualEditor is essentially engineering 'Against the odds'.
  • 74:19 - 74:22
    And so in fact we have found that the odds are against us.
  • 74:22 - 74:29
    But can anyone guess what makes creating VisualEditor so difficult ?
  • 74:29 - 74:33
    Like what sort of things are standing in our way ?
  • 74:33 - 74:37
    - The community
    The community.. definitely NOT !
  • 74:37 - 74:41
    The green shirt ?
    - Ehm browser support ?
  • 74:41 - 74:49
    Having to support like everything like IE6 and mobile ?
    - Oh [....] I don't think we ever claimed IE6 support...
  • 74:49 - 74:52
    Anyone else ?
    - Working with wiki text
  • 74:52 - 74:58
    Ah, yeah OK now we are getting good
    So yeah definitely differences in Operating Systems
  • 74:58 - 75:04
    different kinds of computers people are using..
    That includes like laptops, tablets, phones.
  • 75:04 - 75:10
    We are moving towards getting mobile support going.
  • 75:10 - 75:18
    And also.. It turns out even for modern browsers this is still a problem. I mean these are not the IE6.
  • 75:18 - 75:24
    Ehm.. but... even in modern browsers there is a lot of huge differences even at this point in time.
  • 75:24 - 75:28
    And they don't really seem to agree on how standards should be done
  • 75:28 - 75:31
    at least not when you get down to the nitty gritty details.
  • 75:31 - 75:35
    And eh we sort of demand a little rigor
  • 75:35 - 75:42
    But also yes, wikitext. It is a huge issue for us. There is a lot of ambiguities, there is lot of limitations,
  • 75:42 - 75:45
    there is a lot of design flaws and they bubble up into the User Interface
  • 75:45 - 75:49
    and users get really confused about what is going on.
  • 75:49 - 75:52
    because it doesn't quite work the way Microsoft Word works,
  • 75:52 - 75:56
    because wikitext is not the same as Microsoft Word.
    It's a data? format.
  • 75:56 - 76:00
    And so we have to work very hard just to maintain compatibility.
  • 76:00 - 76:03
    And eh... isn't that so sad.
  • 76:03 - 76:09
    But we are really hoping to share some of these experiences with you,
  • 76:09 - 76:15
    not necessarily to make you cry, but because we think there are some interesting challenges,
  • 76:15 - 76:21
    most of which we have overcome and there are some kinda exciting stories to tell.
  • 76:21 - 76:27
    So to tell the first one, I'm going to switch over to Roan Kattouw, who is going to talk to us about Wikitext.
  • 76:29 - 76:33
    Alright, so
    Let's talk wikitext.
  • 76:34 - 76:38
    Wikitext, like Trevor said, is a limiting factor to us.
  • 76:38 - 76:41
    And one of the main problems is that if you are a VisualEditor user,
  • 76:41 - 76:46
    if you are like a VisualEditor-only user, then as far as you are concerned wikitext does not exist.
  • 76:46 - 76:52
    Like it is our job and our goal to pretend to these people that wikitext has never been there
  • 76:52 - 76:56
    and will never be there and they can live in this sort of fantasyland where they don't have to deal with it.
  • 76:56 - 77:03
    Which works [...] for most of our [...] but the reality is that wikitext sort of [..] there.
  • 77:03 - 77:10
    and users might want to do things that you can't do nicely or can't do at all in wikitext.
  • 77:10 - 77:15
    And so it ends up being that wikitext limits the users in what they can do.
  • 77:15 - 77:21
    We can't let them do things that are not representable in wikitext or that produce very ugly wikitext
  • 77:21 - 77:22
    because people will get upset.
  • 77:22 - 77:29
    Which means that certain things are not allowed, but they are totally arbitrary and as a user you don't know why.
  • 77:29 - 77:35
    because you don't know about wikitext, so you don't know about these completely random limitations.
  • 77:35 - 77:42
    I'll show a few examples of like headaches we've had in our [..]
  • 77:42 - 77:48
    In wikitext you can do nested lists.
    You can do this perfectly well in HTML as well.
  • 77:48 - 77:52
    It's perfectly normal, it's the way HTML wants you to do this, is kind of weird,
  • 77:52 - 78:00
    where it wants you to nest the 2nd level list at the end of the previous list item.
  • 78:01 - 78:06
    Which is a little bit weird, but whatever fine, it's how everyone does it.
  • 78:06 - 78:16
    If you insert a line break there, after 'Nested list' and you don't put a star there, then it ends the list completely.
  • 78:16 - 78:20
    and your 'Bar' ends up completely outside of the list.
    That's also fine
  • 78:20 - 78:27
    But, if you wanted to put text after the nested list but within the same list item,
  • 78:27 - 78:34
    so you have a list item 'Foo' and then a nested list and then 'Bar'. You can't do that in wikitext.
  • 78:34 - 78:43
    It is perfectly valid HTML, it's something that initially would almost ... if you did certain things in VisualEditor, [...]
  • 78:43 - 78:51
    but you can't do it in wikitext. So we take all sorts of pains to not allow you to do this, because it creates nightmares.
  • 78:51 - 78:56
    But this is of course completely non-transparent to anyone.
  • 78:56 - 79:01
    And in general we tend to ignore that newline characters exist.
  • 79:01 - 79:07
    You also can't really use formatted text in lists. Wikitext allows you to do it if you use an HTML tag here.
  • 79:07 - 79:11
    But.. and that actually works just fine.
  • 79:11 - 79:15
    But it doesn't really work, or it's not really useful
  • 79:15 - 79:18
    because you try to do this...
  • 79:18 - 79:21
    which, you wouldn't be using a tag if you didn't care about the way your newlines were produced,
  • 79:21 - 79:23
    so you probably are going to add a newline in there.
  • 79:23 - 79:29
    Then it happily breaks your list for you and throws 'Bar' outside the list and into it's own paragraph,
  • 79:29 - 79:34
    because clearly that's what you meant, because clearly knows everything [...] a list.
  • 79:34 - 79:42
    This is superevil. It also shows you how sort of this whole notion of using HTML some places in wikitext
  • 79:42 - 79:45
    doesn't really work, or HTML and wikitext doesn't really get along that well.
  • 79:45 - 79:53
    Obviously this means, that if you have pre formatted text in a list and you try to press enter in it,
  • 79:53 - 79:59
    then VisualEditor needs to do, well not that, because that doesn't work.
  • 79:59 - 80:05
    and if you try to create this HTML here...
  • 80:16 - 80:22
    If you try to create something like this, like if the user tried to press Enter inside a formatted text in a list,
  • 80:22 - 80:28
    this is what you probably would expect to happen, except that it is completely [..]
  • 80:28 - 80:31
    [...] so maybe we shouldn't let you do that.
  • 80:31 - 80:36
    So instead what happens is that if you press Enter inside the list item, then it splits the list item.
  • 80:36 - 80:41
    We never try to insert any sort of line break like thing there, because we know it explodes.
  • 80:41 - 80:46
    And also if you select text in a list and try to make it formatted, we break out of the list.
  • 80:46 - 80:50
    Because we know that formatted text in a list is major trouble.
  • 80:50 - 80:56
    Of course this only makes sense if you [...] and if you are the user, this makes no sense whatsoever.
  • 80:58 - 81:07
    You can also if you [..] in a list, you can also do this in wikitext and it will do what you expect.
  • 81:07 - 81:11
    It will create a paragraph break inside your list item.
  • 81:11 - 81:16
    This isn't the most beautiful wikitext of all time, but it kind of works.
  • 81:16 - 81:18
    You...
  • 81:24 - 81:26
    This works, it's not very beautiful..
  • 81:26 - 81:33
    This is basically what you would get if we [..] work in their own way and insert a paragraph break.
  • 81:33 - 81:40
    So obviously the solution is to not let the user create paragraphs breaks in list items and they have no idea why.
  • 81:40 - 81:48
    One of my favorite examples is the [...] link syntax in wikitext is so amazing.
  • 81:48 - 81:52
    You would think that you can totally embed an image inside the text of a link.
  • 81:52 - 81:59
    So what this is trying to do is trying to create a link to 'Page' with the link text being 'Foo', an image and then 'Bar'.
  • 81:59 - 82:06
    This seems reasonable, you can totally do this in HTML, you can totally have an image that's like part of a link action.
  • 82:06 - 82:10
    If you try to do this in wikitext then everything freaks out and
  • 82:10 - 82:17
    it decides that the image is more important than the link and it just barfs a bunch of wikitext all over your page.
  • 82:17 - 82:26
    If we let you try to create a link across an image, then it would try to generate the wikitext like that.
  • 82:26 - 82:30
    which would then when you render it back would create this garbage and so we cannot really do that
  • 82:30 - 82:38
    and if you try to link across an image, it will silently cut the link at the image and [..] because we know links and images are trouble
  • 82:38 - 82:41
    Users have no idea.
  • 82:45 - 82:51
    If you wanted to do this, this completely sensible HTML, you should totally be able to do this in VisualEditor,
  • 82:51 - 82:59
    except we don't let you, because if you then try to put the wikitext back, it will be [..]
  • 82:59 - 83:04
    So those are things that were just broken in wikitext, which means you can't do them in wikitext,
  • 83:04 - 83:09
    but there are also things that you can kinda do in wikitext except the result is so ugly,
  • 83:09 - 83:13
    that people that do use wikitext yell at us whenever we do it,
  • 83:13 - 83:18
    and so we also try and nudge users away from them.
  • 83:18 - 83:24
    One of these things is,
    is with links.
  • 83:25 - 83:29
    This is a feature in wikitext where you have link trails.
  • 83:29 - 83:37
    So if you try to create a link to 'Foo', followed by the word 'bar', you would think that you would [..] like that
  • 83:37 - 83:41
    but in fact that doesn't actually work that way, because wikitext is helpful and does link trailing.
  • 83:41 - 83:46
    Where if you write text after a link, it automatically moves it into the link.
  • 83:46 - 83:51
    So if you are trying to do the conversion like on the first line, it would actually break on you,
  • 83:51 - 83:54
    because if you then try to convert it back to HTML you'd get something different.
  • 83:54 - 83:59
    and it would actually go and help you and put bar inside the link
  • 83:59 - 84:07
    and so instead we have to use a nowiki tag and people started crying and yelling at us for inserting all these [..]
  • 84:07 - 84:14
    The solution to this problem, if you can call it that, is to, when users type text at the end of the link,
  • 84:14 - 84:20
    try and make sure that by default that text is always part of the link and so you try and nudge them into creating
  • 84:20 - 84:25
    content that looks like the thing on the 2nd line, which works and try to make it harder for them
  • 84:25 - 84:30
    to create content looks like the thing on the 3rd line, because we know that's trouble
  • 84:30 - 84:35
    This kind of behavior steering is, kind of like, it sort of promotes harmony,
  • 84:35 - 84:39
    because VE users ended up creating wikitext that looked hideous and that people were upset about..
  • 84:39 - 84:48
    But.. you know, it's not a real solution and it's completely [...] to people who use it.
  • 84:48 - 84:55
    You can also put spaces at the beginning of paragraphs, which [...] VE.
  • 84:55 - 85:00
    You would think that we would just generate wikitext with a space at the beginning,
  • 85:00 - 85:05
    unfortunately it doesn't work that way, because a space [..] meaningful [...] a tag.
  • 85:05 - 85:11
    So what we actually have to do is wrap the space with a nowiki tag and again people get upset at us.
  • 85:11 - 85:21
    We haven't even solved this problem yet. We think that we might want to detect these spaces
  • 85:21 - 85:24
    and deliberately ignore them and throw them away.
  • 85:24 - 85:28
    But you know, you can't really do that, that's not a real solution to a problem.
  • 85:28 - 85:33
    It's just like trying to steer around various pitfalls again.
  • 85:33 - 85:41
    Here is another example. You can type '#3' and also you can try to naively serialize that.
  • 85:41 - 85:46
    But it doesn't do what you expect, because # means that you are trying to do a numbered list.
  • 85:46 - 85:49
    So you have to wrap the # in a .
  • 85:49 - 85:55
    Which again, we try to discourage people from doing this, by throwing: "What you typed looks like wikitext"
  • 85:55 - 85:57
    "This won't really work, are you sure you want to do this?"
  • 85:57 - 86:01
    Which a more egregious example of this would be
  • 86:08 - 86:13
    Which a more egregious example of this would be this, where the user actually tries to type wikitext in VE.
  • 86:13 - 86:18
    We come up with a big flashy warning: "This won't work the way you expect it would"
  • 86:18 - 86:24
    and if you do save that actually have nowiki tags.
    We can't really prevent that, because this is what we
  • 86:24 - 86:27
    have to do, to give a faithful representation [...]
  • 86:27 - 86:32
    So instead we just surface a warning and go like: "Well people don't really like you to do this"
  • 86:32 - 86:35
    But we can't really stop them.
  • 86:35 - 86:44
    We have also considered converting this to a link, but we are trying to pretend wikitext doesn't exist.
  • 86:44 - 86:47
    so that would be incredibly confusing for people who have never used wikitext
  • 86:47 - 86:51
    and they mash some buttons and all of a sudden they have a link and they have no idea why.
  • 86:51 - 86:54
    So I talked about solutions to these kinds of problems,
  • 86:54 - 86:58
    and these are just a few examples, there are like a lot of other things that we steer around,
  • 86:58 - 87:05
    but they are not really solutions, they are 'solutions' in air quotes, because they are like the lesser of all evils.
  • 87:05 - 87:11
    we should try and nudge people to do, what we think is the right thing, but the reason it is the right thing,
  • 87:11 - 87:20
    is [...] understand, so it's just a bunch of crappy workarounds. It's not really [...]
  • 87:20 - 87:24
    So now Trevor is going to talk about Browsers, which I'm sure we can all agree are lovely things.
  • 87:26 - 87:29
    I recommend them.
  • 87:30 - 87:31
    So more specifically to the [...]
  • 87:31 - 87:36
    I'm really only going to be talking about a browser feature known as ContentEditable.
  • 87:36 - 87:40
    It is a very magical feature that browsers provide.
  • 87:40 - 87:45
    Probably the richest feature that they have ever introduced.
  • 87:45 - 87:51
    It makes HTML like this..
    editable by simply putting a switch.
  • 87:52 - 87:57
    Job done. Let's go home now. We are all sorted.
  • 87:57 - 88:04
    But.. It turns out that of all the wonderful features browsers have given us over the past decade or so
  • 88:04 - 88:10
    this is not one of them.
    ContentEditable is really inconsistent.
  • 88:10 - 88:14
    It is very overzealous and it's very annoy able.
  • 88:14 - 88:19
    You are basically always in a defensive position, trying to figure out what just happened.
  • 88:19 - 88:22
    It doesn't even have events. It does weird things.
  • 88:22 - 88:25
    Based on what day of the week it is, which way the wind is blowing.
  • 88:25 - 88:31
    Depending on which browser you are in and what OS you are on.
  • 88:31 - 88:35
    I think there is a math.random() somewhere in there. I'm not really sure.
  • 88:35 - 88:41
    We had this idea early on... let's just avoid ContentEditable full stop.
  • 88:41 - 88:43
    We worked on the WikiEditor.
  • 88:43 - 88:49
    We tried to make a syntax highlighting version of wikitext editing in a ContentEditable and we ran into a lot of issues.
  • 88:49 - 88:54
    So we just figured, let's just make a synthetic surface, this is what Google Docs does for instance.
  • 88:54 - 89:02
    [..] ContentEditable, all the text selection and the blinking cursor and all of that is done with just rendering divs
  • 89:02 - 89:05
    And we dit it.
    And it worked.
  • 89:05 - 89:13
    But.. even though we had full control, we also had all the responsibility to implement everything from scratch.
  • 89:13 - 89:19
    And that is where we got this limitation.
    Things like spellcheck and when you type on mobile
  • 89:19 - 89:25
    pressing spacebar twice, what does it do.
    And different IME's, and what happens if you swipe.
  • 89:25 - 89:32
    And mobile text selection is also a big problem, because it works very different and looks very different
  • 89:32 - 89:36
    from the way it does in desktop browsers.
  • 89:36 - 89:40
    All these things are stacking up against us and we sort of maybe we have to revisit ContentEditable,
  • 89:40 - 89:47
    because we were quite limited in what we were able to accomplish.
  • 89:47 - 89:53
    So we realized that the reason that our ContentEditable experience was so bad,
  • 89:53 - 89:57
    was because we were making the DOM the center of our application.
  • 89:57 - 90:00
    That everything in our application, the Data was in the DOM
  • 90:00 - 90:05
    and the ContentEditable was having it's way with it, without our permission, most of the time.
  • 90:05 - 90:10
    And the View, which was ContentEditable, was right there in the DOM.
  • 90:10 - 90:17
    And of course the controller was relying on events from the DOM. That's what put us in that defensive position.
  • 90:17 - 90:21
    The truth is that this was they way ContentEditable was designed to be used.
  • 90:21 - 90:24
    So it seemed sensible. But it really set us up for failure.
  • 90:24 - 90:29
    We realized that what we needed to do, was to come up with a different architecture completely.
  • 90:29 - 90:34
    Where we simply just use ContentEditable for the little things that it is good for, like rendering
  • 90:34 - 90:43
    text selection and some, but not all, of our input, because even the events that it gives sometimes are telling lies
  • 90:43 - 90:50
    so we pretty much have to monitor it, repeatedly, over and over and over and check up and see what it is doing
  • 90:52 - 90:55
    It is sort of resource intensive.
  • 90:55 - 91:03
    This whole experience is really just taught us one thing: Browsers are dangerous.
  • 91:03 - 91:06
    They lie to you, they will waste your time.
  • 91:06 - 91:12
    They are bound to make you look foolish, and they are toys.
  • 91:12 - 91:16
    Using a browser to make an application on Wikipedia, is like using my 7 year old daughter's
  • 91:16 - 91:23
    play kitchen to run a restaurant. Everything seems to be there, but you got to use your imagination.
  • 91:23 - 91:29
    And that is what I think a lot of VisualEditor engineering is, coming up with very imaginative ways to
  • 91:29 - 91:34
    overcome the toy-like state of browsers.
  • 91:34 - 91:42
    Which we hit all the time. So my recommendation to anybody doing [..] development, is to: Protect yourself.
  • 91:42 - 91:48
    By scrapping. And that is exactly what we do. That is the architecture that we came up with.
  • 91:48 - 91:53
    You scrap the DOM completely, to the point where we are really seeing it as a thin rendering client
  • 91:53 - 92:01
    with some input and keep browsers on a very short leash and to give them a minimal amount of control.
  • 92:01 - 92:09
    That is my recommendation to you all. And now to talk about the troubles of Operating Systems..
  • 92:09 - 92:13
    and how they effect our work, is: Ed Sanders
  • 92:13 - 92:16
    Hello
  • 92:21 - 92:27
    So I'm going to talk to you about something specifically bad about ContentEditable,
  • 92:27 - 92:30
    which is: copy-paste.
  • 92:33 - 92:37
    Here is the good news: ContentEditable gives you copy paste.
  • 92:37 - 92:42
    You can press Ctrl-C, put stuff on the clipboard, you press Ctrl-V it takes out of the clipboard
  • 92:42 - 92:49
    and that is pretty much half the job done for you. We don't have to [..] the data in some fake clipboard
  • 92:49 - 92:53
    intercept key events and [..]
  • 92:53 - 93:01
    There is even more good news. Brought to you by Clippy. It has a bunch of events that are actually quite useful.
  • 93:01 - 93:08
    So not only are there oncopy and onpaste events. But they happen before the copy and before the paste.
  • 93:08 - 93:15
    So if you have the oncopy event fired, that means the data hasn't been written to the clipboard yet.
  • 93:15 - 93:19
    Which turns out to be really useful, because you can actually move someones selection,
  • 93:19 - 93:26
    just before it writes the data to the clipboard and change what goes into the clipboard.
  • 93:26 - 93:35
    Even more good news, there is an API, with getData and setData, so you can write stuff directly into the clipboard.
  • 93:35 - 93:41
    This is only available on copy and paste events. And we can make directly set whatever the hell we want in there.
  • 93:41 - 93:48
    With an asterisk, because if there is anyone from Mozilla here, we need to talk...
  • 93:48 - 93:51
    On to the not so good news.
  • 93:51 - 93:58
    It's really bad. It's really inconsistent. Copy paste is to ContentEditable, what ContentEditable is to browsers.
  • 93:58 - 94:02
    It's like, it's the worst of the worst.
  • 94:02 - 94:05
    If we are talking about Trevor's play kitchen
  • 94:05 - 94:10
    This is like using Play-Doh to make a play kitchen to run the restaurant.
  • 94:10 - 94:16
    It's just, every browser, there is no documentation, every browser does it somewhat differently,
  • 94:16 - 94:22
    and this may or may not change next week.
  • 94:22 - 94:30
    As I mentioned earlier, that beautiful API that would let us do whatever we want in getting the clipboard data,
  • 94:30 - 94:33
    take whatever we want out... only works in Chrome.
  • 94:33 - 94:41
    So unfortunately, we have to support more that one browser, so we need to come up with another method.
  • 94:41 - 94:46
    That will work in Firefox and maybe even IE one day.
  • 94:46 - 94:51
    Let's have a look at what we actually want to do in VisualEditor.
  • 94:51 - 94:56
    We have a couple of use cases. There is the easiest one.
  • 94:56 - 95:03
    Which is to copy some text from the top of your document and paste it a bit lower.
  • 95:03 - 95:09
    In that case, you cannot choose a favorite clipboard, because we can just use the internal data
  • 95:09 - 95:13
    that is already in our model, as Trevor mentioned we have taken the model out of ContentEditable.
  • 95:13 - 95:18
    we store all our data in the [..] So every time we get copy, we can say: "Oh, you selected from 1 to 6"
  • 95:18 - 95:25
    and then when you hit paste, it gives us the same thing, you can just move it out.
  • 95:25 - 95:28
    Do one copy from one VE instance to another.
  • 95:28 - 95:33
    That means, getting all this rich data, like templates or images, and making sure that goes into the
  • 95:33 - 95:36
    clipboard properly.
  • 95:36 - 95:41
    And we also might want to copy into a Word document.
    So we need to make sure that what goes into the Word
  • 95:41 - 95:44
    document is actually, clean HTML.
  • 95:44 - 95:51
    So you might have thought, just copy between the instances, well we can just take our internal data and JSON serialize it.
  • 95:51 - 95:55
    But then if you paste that into Word, then you are going to be like, wow what just happened there.
  • 95:55 - 95:59
    I copied like a paragraph in an editor and now I've got [..]
  • 95:59 - 96:07
    And people may also want to copy stuff from the website and paste it into the.. maybe not so much Wikipedia,
  • 96:07 - 96:14
    because you know [..]
  • 96:14 - 96:17
    So some solutions
  • 96:17 - 96:23
    1. We have this thing called DM HTML, which isn't the ContentEditable HTML, because ContentEditable HTML
  • 96:23 - 96:30
    will randomly [..] your HTML, we keep a [..] copy of the DM HTML, which is what gets send back to the server
  • 96:30 - 96:37
    when you hit save. So we can put that on the clipboard.
  • 96:37 - 96:44
    If you put a template that is a table [..] to the table, replace it with a little marker saying: This is info box [..]
  • 96:44 - 96:51
    So if you put that in the clipboard, when you paste to another VisualEditor instance, you get a template and not just the rendering of a template.
  • 96:51 - 97:00
    which is a table and a bunch of random stuff, [..]
  • 97:00 - 97:07
    If we can also put in the clipboard some sort of marker, for internal copy paste,
  • 97:07 - 97:12
    so we can say, oh this copy actually came from VisualEditor, then when we hit paste we can say:
  • 97:12 - 97:17
    Well this was a VisualEditor copy, was it from the same window that we are currently in?
  • 97:17 - 97:24
    If it is, then we can just draw the data from our internal data structure.
  • 97:24 - 97:29
    So [..]
    Things get easy
  • 97:29 - 97:35
    We can use the plain clipboard data. We put our DM HTML in the HTML part of the clipboard.
  • 97:35 - 97:42
    BTW. the clipboard has a plain text area, an HTML area and sort of random custom metadata.
  • 97:42 - 97:53
    And then we can set a custom key pointing to some internal store for the actual internal data, if they need to be a paste.
  • 97:53 - 98:04
    And that's not too bad. There's a few problems with actually setting the data directly [..]
  • 98:04 - 98:08
    Here is the hard way, which is what happens if you have Firefox or Internet Explorer.
  • 98:08 - 98:16
    You hit copy and as you saw earlier, we have really early events. So we take your selection, which is in the CE.
  • 98:16 - 98:30
    And we then make generous and DM HTML, put it in a hidden text area, move our selection to the text area, then we wait a bit, wait for the copy to happen. [..]
  • 98:30 - 98:36
    And then we put everything back where we found it. So slightly convoluted process.
  • 98:36 - 98:39
    Job done.
  • 98:39 - 98:41
    Not so fast.
  • 98:41 - 98:46
    Mo' problems
  • 98:46 - 98:52
    The ContentEditable clipboard has a habit of tweaking your HTML, so that it looks better.
  • 98:52 - 98:58
    Internet Explorer in particular throws away lot's of whitespace, that's not so bad.
  • 98:58 - 99:06
    Firefox, [..] we need to talk again. They throw away, a whole bunch of attributes, such as RDFa.
  • 99:06 - 99:11
    That's quite unfortunate for us, because we use RDFa to define all template metadata.
  • 99:11 - 99:18
    So if you are in FireFox and you try to do this, you just throw away all your template metadata and you just be left with [..]
  • 99:18 - 99:21
    We can work around this by serializing all the templates
  • 99:21 - 99:30
    which we think CE might destroy, which we put in another template [..] another attribute [..] won't destroy.
  • 99:30 - 99:33
    Element destruction
  • 99:33 - 99:39
    Empty spans, we use empty spans in Mozilla to store this internal templating and then Mozilla decides to destroy it.
  • 99:39 - 99:42
    Because you didn't mean to have an empty span there right ?
  • 99:42 - 99:48
    So a little hack we can do there is to have a [..] and that sort of protects it... atm.
  • 99:50 - 100:03
    And reordering. If you sort of copy just a table cell and try to paste that in a paragraph it might sort of wrap it in tables, it might move the paragraph outside [..]
  • 100:03 - 100:12
    so we need to make sure that when we do do this fake paste [..] trip, that we paste into the right sort of content.
  • 100:12 - 100:17
    End..
    Almost
  • 100:17 - 100:22
    As I've mentioned. We don't think we've got this completely sorted out.
  • 100:22 - 100:28
    We get reports of bugs. We'd love you to try and just fire up VisualEditor in your browser,
  • 100:28 - 100:38
    copy and paste and stuff and then people get it to break again.
  • 100:38 - 100:55
    And also as I've mentioned a few times, [..]
  • 100:55 - 100:59
    And that was that.
Title:
Social Machines X Reaction
Video Language:
English

English subtitles

Incomplete

Revisions Compare revisions