 Yeah, this is what trivia night is going to be like, too. Just will put a question up on screen. I'll shush anyone, it's quiet. Actually that is an excellent point. Trivia night, tomorrow night should be a lot of fun. Also the Lullabot party at Handelbar, tonight at 7, and Sprints on Saturday, there's still a whole lot of Drupal, a whole lot of DrupalCon left to go. So much Drupals. Okay, hi. Thank you. There's a seat up front for anyone who wants to actually be within throwing range of me. So the battle for the body field, this is in no way an incendiary title or anything. Anyone who has participated in the Drupal universe for more than a short period of time is probably familiar with arguments about WYSIWYG editing. Does anybody ever run into an argument about whether to use one, whether we should have one standard built into Drupal, whether you should turn them off and just teach people to use markup so they aren't lazy. We should just make them magically better. We should figure out how to embed Dreamweaver in a text area. Anything in between those spectrums. I mean, I don't think it's overextending to say that this has been a contentious topic in our community. And it's actually come to the forefront in the past couple of years because we actually are going to ship with a really high quality WYSIWYG editor in Drupal 8. This is fantastic. So it won't even be something that you have to go and dig up because your client told you absolutely you have to or someone in your company said, by God, we can't figure out how to make bulleted lists or something like that. It's just gonna ship with Drupal 8. So it's cool on some levels but it's also reignited a lot of heated debates about what the right way to use a WYSIWYG editor is, whether people should have them at all, whether they're an abomination that should be cleansed from the earth, whatever. Thus, Rock'em Sock'em robots. I think one of the problems is that we've been having entirely mistaken arguments about this. We've been fighting about the wrong things for quite a few years. We've talked about it as a conflict between ugly, crappy markup that we think WYSIWYG editors generate versus clean markup. Talking about looking at it as a tug of war between lazy content editors who don't want to learn HTML and markup literacy and understanding the tools of the web. Maybe that's the real conflict we're looking at. Maybe the answer is markdown. The answer is not markdown. It is not. We will get to that later. I love markdown. I do all kinds of stuff with it. But the answer to this particular problem we're going to be talking about is not markdown. And maybe the answer is easy versus hard. We just have to accept that certain kinds of things that people need to do in working on the web and in creating content will just have to be hard. And they're going to have to learn that. It's not simple versus easy, a few things versus a lot of things. That's a lot of these subjects that we argue about are missing the point. I love that effect. So for anybody who is interested in just leaving after five minutes and going and getting a beer, this is basically the rundown. There are four really important things that we often miss when we fixate on WYSIWYG editors as the heart of this problem. One, is anybody familiar with the idea of blobs of content versus chunks of content? Okay, the chunks versus blobs thing goes around in the content strategy community a lot. It was coined by Karen McGrane in her book, Content Strategy for Mobile. But it's the idea of we break things up into lots of individual fields so they can be remixed and repurposed and shifted around in different layouts and stuff like that, and that's cool. But the problem is just treating it as a battle between big blobs of HTML and wonderful tidy little chunks that we can reshuffle is insufficient to solve a lot of the complex content problems that we have. It's an improvement, but it doesn't go all the way. The other issue is that HTML in and of itself is insufficient to represent most of the content that people are creating on the web. It's sufficient to represent how it looks in a browser, but not the meaning of the content itself. There's a vocabulary mismatch between the two. We'll get to what exactly that means later. The third point is that there are communities that have been tackling these weird tangly problems of what to do with semi-structured stuff. Things that have long narrative flows and they need to be editorially controlled and written by a human being. But they also have little pockets of structure that need meaning and need to be at particular places. That's the kind of problem that the XML community and people in communities like the Ditta, anybody here use Ditta? I'm sorry, you rock. They've been tackling and chewing on the hard problems about semi-structured content for a long time. There's tons of lessons we can learn from them. And then the real concrete takeaway in the Drupal community that we can really learn is that we need to stick to storing meaning rather than complex markup structures and then transform them on display into the kind of structures that we want for representational purposes. And again, we're going to go into the details of what exactly that means, how it plays out and great tools that can make that easier. But that's the gist of it. If you have any significant disagreements with any of these things, you can in fact throw things at me, mostly if you're in the front, because I don't want you to hit anybody. But go for it. This is a core conversation, so it's hopefully a little more raucous. Wow, everybody is so quiet. Your turn first. Oh, I see. Got it, Larry. That's Larry. We know how this is going to go. I agree. So the really, really hard problem that we are familiar with, that I think our community and a lot of other web publishing communities have learned is the hard problem and figured out solutions to, is that for many, many years, this is how we made web pages. A web page was a file on disk and a URL that was accessed by a web browser and a piece of content. And it was handcrafted by artisanal web monkeys in a copy of BB Edit or Ultra Edit, whatever you used. And you sweat bullets. And Morton, I think, comes from the school of you create pure, wonderful markup. And then you separate the presentation from it with CSS. It's great. And this is actually an incredibly flexible, incredibly powerful way to create a piece of HTML content. The problem is, in the real world, what usually ends up happening is a WYSIWYG editor gets thrown on top of that, because not everyone is like an HTML artisan who wants to craft some sort of wonderful piece of HTML art. And this is what people end up editing documents in. And that is actually Comic Sans. And it is blinking. And that is, I am told, although I am red-green colorblind, I'm told that is magenta. That is what we often encounter in anybody who's done a large-scale migration on an existing site, either where they had lots of handcrafted HTML files they had to migrate into a CMS, or where just a WYSIWYG editor has been turned on and all the buttons were available. You get monstrous stuff. You get pages that looked exactly like somebody wanted them to at the very moment they were created. But the problem is, is all of that crap that's being built, A, breaks the minute anything changes in the design. That's assuming that the people with that direct markup control are very scrupulous and always make sure that their work perfectly matches the design standards and the design guide for the website, because that's what everyone with the WYSIWYG editor does. They look up the brand guidelines and they make sure they've got the right styles. And if there's anything that they don't see any guidelines for, they go to whoever designed the website and they make sure it'll fit in well. But then, even assuming that best case scenario, the minute the site gets redesigned, all of that markup that they put in there is just dumb, raw markup that has to go back in, be edited, be updated. Even assuming that you have the regular expression guru ultra genius that's still a huge amount of work to do on any site. The other one is that content reuse suffers massively. In Drupal, I think we practice tons of content reuse without even really thinking about it in the way that the larger content strategy community works. The ability to create a piece of content, show its title in a sidebar list of links, show a teaser for it on another listing page, show a full version, have different permutations of that piece of content being displayed in different ways, in different places, and to edit one single piece of content and to have all of those things reflect those changes, that's content reuse at its basic form. Now, that doesn't even account for things like going and repurposing that content on other websites, pushing it out to other platforms via feeds like RSS and stuff like that. But once all of that stuff gets baked into the content, the body field, reuse suffers massively because it doesn't fit with other designs, it may break other websites, all kinds of nasty stuff. And then finally, this one has been a really, really big issue over the past couple of years as everyone and their dog gets a mobile phone that has a web browser and everyone starts using it instead of all their other computers or whatever. That kind of design, the handcrafted, artisanal web design jammed into a WYSIWYG editor or whatever, that tends to break mobile browsers or tablet browsers or telephone browsers or Google Glass or whatever random crap people decide they're going to want to access content from. At this point, that's not even an annoying edge case. The number of users who are using mobile phones primarily or even exclusively is rising steadily over time. Especially if you're in an organization that really cares about accessibility or there are legal requirements about how your content can be accessed, this is a huge, huge issue. And that's really the heart of it. This idea of an HTML page that we design and we create and throw out there to the wind, it breaks in all those scenarios. We've come up with awesome solutions to this in the web CMS world and especially in the Drupal world. Field API, views, we have all of these tools that have been present in our community for years that have made a better approach, a chunkier approach, create little blocks and put them together and make your piece of content out of a title and a subject line and all that kind of stuff. This is a huge improvement. It's, I mean, for people who remember being the webmaster of a web page or the homepage for your company or something like that, you remember how awful it was doing very simple edits to the site and the kind of chunky field-based approach that we use, taking individual pieces of a type of content, piping it through templates to handle all of the crafty, you know, the crafty markup that wraps those individual bits of content. That's a big shift. We've replaced this with wonderful things like this. Does that make everyone's heart just swell with joy? Awesome, it's fantastic. It's enabled so many cool things. And in the Drupal world, we even have a really mature, rich API that you can drop new types of fields, new ways of remixing them, stuff like that. The problem, and there is still a problem with this, is that as much as we try to chunk things up and as wonderful, wonderful of a job as we do, we still end up with these nasty, crappy little mini blobs embedded inside of our wonderful chunky content models, which is where the body field lives in one of those miniature blobs inside of the wonderful idyllic, platonic, chunky content. And that's why turning on the WYSIWYG, yes, I need a chorus. And that's why turning on the WYSIWYG editor in the body field is one of those incredibly common things because as much as we wanna tease out all the individual stuff, the body field is where all kinds of things, unpredictable things, stuff that we can't really figure out what it's gonna be until somebody tries to jam it in there. That's the kind of stuff that lives in there. And that's my worst case scenario. I didn't introduce myself, I'm Jeff Eaton, I work for a company called Lullabot. We do lots of large content websites. Martha Stewart, MSNBC, MTV UK back in the day. So I have WWE for people who like men throwing each other around. Who doesn't? Indeed, who doesn't. One of the most common use cases we run into is yay, hurray, chunky content, field, stuff like that. But I really need to put these three photos in a gallery right here in the article. It can't be in the sidebar. It can't be automatically just stuck in near the top of the page or something like that. No, I've written an article and at this point in the narrative flow of that article, I really need this thing to live there. And I tremble to think how much human energy has been lost trying to argue editorial teams and content creators out of that very simple need. No, do you really need it? I'll bet if we just always put it after the third paragraph, that would be fine, right? No, it turns out, as much as we can push back and we can negotiate, that is a really, really, really common kind of problem. And it's not exclusive to photo galleries in news articles. It occurs all over the place. This is the harder problem. Although chunking things up and using templates to reshuffle and remix individual little pieces of content, utilizing structured content in that way, that's given us huge, huge gains, but this remains. The first element of this really tangly, difficult problem is narrative text. I don't necessarily mean like storytelling. I mean, some flow of text in which a human being's like narrative energy, their creative telling of some sort of piece of information is important. It's not simply being assembled out of individual little bits. This is like a conversation or a sales pitch or a piece of news taking somebody through like the inverted pyramids, stuff like that. Something that a person is writing. Common cases that we end up seeing are like long reports. Like there are a lot of federal agencies, they publish their content on the web and they have huge reports that are basically a single long narrative document with all these pieces, whether it's complex figures in charts or data tables or pull quotes and statistics and stuff like that, littered liberally throughout the flow of the document. You can break it up into chapters. You could, if you were really debauched, you could try to break it up into pages, like traditional pages of a report or something like that, but you'd still be left with the fact that there are islands of structure inside of that big flow of narrative. And the placement of those little islands of structure really, really matters. You could get away with putting them all in footnotes depending on how you're presenting it, but it matters that the reference to it at least lives at a very specific place. I don't wanna beat this horse too badly, but like these three things, if you've only got two of these problems, any two of them, you can usually get around the real nastiness of it, but if you've got all three of these things at once, you're kinda screwed. This is an example of a page from msnbc.com. I keep vlogging that because it's a site that we just launched. We're happy to talk about it, stuff like that. And this is a wonderful example of the problem, like in its simplest form. This is a picture of Pope Francis. There's a little description of the photograph. There's credits for the photograph, listing who took the photo. In some cases, there's also a title at the top of the photo. Sometimes there aren't credits. Sometimes there's a link off to another story that the photo came from or something like that. This is an island of structure. It's got maybe four or five different little elements. It has to go at that particular place in the story. I tried arguing with them about whether it really had to go there or not, but it turned out it had to. And this is super common on news sites. If we were just willing to have an image in there, we could just say, okay, cool, HTML tag. HTML already handles that, images, congratulations. And if we were really, really crafty, we could say, well, I bet you could jam that entire caption into the title tag or maybe the alt tag of the image. And then I bet we could just do something crafty with jQuery and reshuffle those. But then where does, where do credits go? What is credits in terms of like the alter title tag? It gets unwieldy really fast. And if you've worked in like news publishing or anything like that, you've heard people going on and on about the Snowfall article that the New York Times produced. It was this giant, intense multimedia experience talking about a group of hikers that got stranded in an avalanche in the middle of the mountains. Gripping story. It is filled with little bits like this. The first time a particular person gets mentioned in the article, their name is highlighted and over in the sidebar alongside the portion of the article that talks about them, there's a bio of them. It's John, he's 29, he's an editor of Powder Magazine. And if you actually click on that, it expands into a little bio. Some of them expand into little video interviews with the person. All kinds of craziness, cool stuff. Very, very compelling, high engagement. And then at various points, illustrating important key pivotal moments in the story. They have these little galleries embedded in it. Oh, wonderful, a gallery, everyone loves galleries. There's descriptions, there's individual photos. Depending on what your device you're on, you can actually flip through them there. Or you could go to a different, a little pop-up could display them. There's all sorts of ways you could display a gallery. But in this article, they did it a certain way. The problem is, a Snowfall article was like this giant moonshot effort with a pile of developers and front-end designers and writers and stuff like that. This is not a sustainable, reproducible kind of thing because of all of the random crap that had to be woven in here. This was not a writing exercise. This was not a content production exercise. This was a web development project in and of itself to create all of this stuff. Somebody out there is thinking, ah, that's why we need semantic HTML. Then we can just CSS our way through all this stuff. No. No, that is not the answer. Semantic HTML is great. And I love the fact that CSS and a huge emphasis on browser standards and cross-browser compatibility has meant that we're no longer jamming all kinds of crazy, weird, crappy, cruft and pixel spacers and stuff like that into our HTML to make it just so. But the problem is, no matter how semantic our HTML is, and this is, I think, about as semantic of a version of a photo gallery as I could come up with. Son of a, well, I'm gonna blame Keynote. I don't know why, but that's just safe. It's Keynote 6. Oh, that's a good one. Yeah, yeah. Always leave in a misspelling so the client feels they can contribute to the meeting. Yeah, that's well played. So, barring the fact that this will break, I think this is actually pretty semantic. I'm using a figure tag inside of the figure tag. I've got an unordered list of links with images. So each one of those images in my gallery links off to a separate page for the individual image. I've got a caption here in a semantically appropriate big caption tag. It's all awesome. There is nothing in here that I could say is design or presentation that's embedded in that except for the fact that there's three photos. Instead of five or two or seven, there's a caption that is a snippet of text that links to another page as opposed to a longer narrative description or a title or credits. There are design decisions deeply embedded in even the most semantic HTML. And if I'm looking at something that can be reused or repurposed or adapted in the future, I need to think about not just how pure and perfect the HTML is, but also what meaning I'm actually capturing with that pure and perfect HTML. And that's a really big issue even with the most semantic sites. No, semantic HTML, not the answer. The deep problem that we keep facing is that there's a difference between browser meaning, the primitive building blocks of an HTML page and content meaning. The idea of a gallery is not something that HTML has a vocabulary for. It has a vocabulary for the individual pieces that make up a particular presentation of a gallery. And it's really good at that. And we can solve that with semantic HTML, CSS, JavaScript, stuff like that. But it doesn't have any way to say, I have a gallery, it should go there. And this vocabulary mismatch goes all through the entire language that we're using to represent our content. I don't wanna knock on any of the really, really useful additional semantic tags that have been added in the HTML5 standard, but things like a side, which is great for call-outs and sidebar pieces and stuff like that, doesn't necessarily capture that this is a teaser for an individual piece of content. The article tag in HTML5 doesn't really distinguish whether something is an article in and of itself or a representation of another article that really lives somewhere else. These are things that we have to build out of those HTML primitives. Things like a list versus a gallery or a paragraph versus something that is an author bio. In the future, if you decide that on your website, what an author bio is and how it gets displayed and whether it always shows up or whether it needs a photo or whether it's just a link or something like that, those are questions that are not really affecting whether an article has an author bio, but they ripple out into design changes that gets us back into this whole structural HTML problem. I'm gonna quote myself here. It's my presentation. I can quote me. HTML is rich enough for a designer to represent complex content, but not precise enough to describe and store that content in a presentation-independent form. There's that vocabulary mismatch we were talking about. And the real problem for us when we build content management systems or things that other people will be entering content into is that the WYSIWYG tools that they need to deal with these piles of HTML primitives that they're forced to use if they need to go beyond italicizing and underlining things is that the WYSIWYG tools we're giving them actually can make the problem worse because rather than shielding them from the complexity of HTML and the underlying little browser primitives that HTML describes things in, we're making it easier for them to slam HTML primitives into a box using easy clickable buttons, but they still have to figure out how the heck to build the conceptual content stuff they're told they need to make out of these primitives. It's like giving someone a dictionary for the wrong language and asking them to go write an article. That's the real heart of the WYSIWYG problem that we keep running into. It's not that buttons are bad or easy is bad or people are lazy. It's that we keep giving them the wrong tools. And the results are predictable. It doesn't necessarily mean that WYSIWYG editors are bad. It just means that we have to think really, really hard about what it is that we give people with them. And also, it means that simply stripping down the WYSIWYG editor so that all they have is like basic italicized format, underlined, linked, strong. Just doing that doesn't actually help that much because unless they're only editing extremely simple content, when they need to actually represent this complex stuff that lives in the flow of their text, well, they're just gonna come back and say, I think I need a div to tables. Can I put tables in there? I need to put things in there and we're gonna get right back to it. That's where the pure HTML, the pure perfect markup in the body field thing usually ends up running aground because at the end of the day, people do need to put goofy things in there sometimes. So meanwhile, I said I was gonna talk about Ditta and XML and all that crazy stuff. Has anybody ever heard of Ditta before? Or are they familiar with it? Okay, oh, wow, awesome crowd, thank you. Thank you for being Ditta people here. It's the Darwin information typing architecture. It's like a particular variant of XML that was created initially for technical documentation. And when I say technical documentation, I don't mean like a blog post on how to use form API. I mean like the manuals for a 747 that come on a binder full of CD-ROMs, full of text. Like that's the kind of scale of content reuse and content validation. That's the kind of stuff that Ditta was designed for. An example would be I think most of the versions of the documentation for the Adobe Creative Suite, 14 languages, two platforms, God knows how many programs, all of those were written and edited in Ditta. It's a very, very serious standard. Also, it's all about lots of XML files sitting there and not really any concept of a database system. So while the Ditta people have figured out how to deal with all kinds of fluid, dangly complex, semi-structured content in large narrative flows, we can still sort things without hiring a Java developer. So let's not underplay what we've achieved. That's sort of my mental picture of the XML in Ditta world. They're doing crazy things and they've got huge amounts of content. But strangely enough, there's like very, very little communication between our worlds. It's very, very different. This is an example of some Ditta. It looks like pretty familiar. Anybody who's worked with XML can probably look at it and figure out what's going on here. It's the main wrapper tag here is a task. And in Ditta, because it's all about technical documentation, task is one of the top-level primitive elements that you can use to describe stuff in your content because you're often walking people through descriptions of a task they're about to perform. And there's a title for the task. And there's a task body element. And inside of the task body, there's a steps wrapper. And step one, step two, step three. There's an interesting little bit here. You can put an audience property on an individual step element and say, this step is only for retail employees of my company, but this step is only for corporate employees. So when this document I'm creating finally gets rendered out to the final webpage or printed out in a manual, I could have the retail version of my manual and the corporate version of my manual. Or perhaps if I'm doing it on a webpage, if somebody's logged in as a corporate employee or if they're logged in as a retail employee, I could switch those things as necessary. And then down here after all these tags are closed, there's a paragraph tag. And it's got this weird little attribute called a conref in Ditta world that's a content reference. So it's pointing at another XML file living somewhere. But this is text that will be replaced by boilerplate legal disclaimer. It has this idea of like placeholder stuff in your page that what you're really doing is pointing to somewhere else in your pile of content and saying, after all of these steps, slap in the boilerplate legal text at the bottom. Now we're used to handling that stuff again with like templates or themes or page level things that the content editor never needs to know about or never needs to care about. But in these large complex content scenarios where they're making this narrative flow, things like that gallery that we were talking about earlier actually representing it with placeholders in the flow of the document and dealing with its structural needs somewhere else kind of makes sense, I think. I'm leading towards it. I'm suckering you into agreeing with me. So some of the really important principles that the Ditta community and the XML community have internalized are, one, you model and store like in the actual markup of your documents, only the meaning. Task, step, task body, title, things like that. Those are very precise terms that their community uses to explain what this thing I'm entering in is, not how it'll look, not how I think it's gonna be used, nothing along those lines. They're not using unordered lists or ordered lists to represent those tasks because although an ordered list is handy, that's not a series of steps we are asking you to perform. It's just an ordered list, an unordered list. Ah, U-L, O-L, whatever. And that's a really important principle. An example would be like a tag like warning and type of hardware and the content of that tag, the content of that element is do not turn off the server. Now, if we were just throwing some content up there, it'd be easy to say, well, how about we just wrap it in a span and put class hardware warning or something like that. And from a pure HTML design perspective, thinking in terms of someone who is making an HTML page, that actually is perfectly fine. But from a content perspective, a div with a class of hardware warning is not the same thing as a warning element with a particular type. We're capturing meaning here regardless of how it ends up getting processed. And if you've ever actually tried to write jQuery against stuff that people have had to enter in a WYSIWYG editor, and they've been told that they're supposed to use certain styles, they're supposed to use certain things to get it to behave properly. Classes, while perfectly handy, are not a great way to capture real structural meaning. They're a great way to pass on information to CSS and even JavaScript and stuff like that, but it's not perfect. The second thing that's really, really core in the Ditta community and the XML world is the idea that they extend a core vocabulary rather than expecting one particular standard to encompass every single user's terminology needs and markup needs. For example, Ditta, although it is not HTML, still borrows a lot of the tags and element types from HTML, things like M, Strong, the P tag for wrapping paragraphs, things like that. It uses those. And the core Ditta standard, it's assumed that you will extend on top of it with what they call specializations. For example, technical documentation is what Ditta was originally designed for, but documenting, let's say, the things that a hospital worker needs to do while they're on their job may imply completely other vocabulary that will need to be present in the markup for it to actually capture the structural meaning. So there are lots of different industry-specific specializations there. And you can do things like use an A tag and you could add, say, an attribute like this is an unverified link or it's a link that we've already vetted. You can add additional meaning onto there beyond simply stylistic information in CSS. But again, the core idea is there's a consistent base vocabulary, but it's assumed that it will be extended for specialized needs. The other one is they're big fans of placeholder markup. Rather than embedding a giant blob of structure inside of something, whenever possible, placeholders are used to pull in stuff from other content resources. Now, in the XML world, that usually means pointing to another XML document somewhere and embedding it inside of this document. For us, that can mean things like pull in a node, pull in node 23 and display its teaser inside of the body of node 48 because my gallery is over here, but this is the node that I want to display it in. Or you could do things like, show all of my attached image fields in a rotator right here. Rather than using the templates to display, to determine where they are, I'll store them in a field, but I'll show them right here in my document. The other one is, assume that there is an additional step beyond simply entering the content before it actually gets sent out to a browser or an iPhone or whatever. It's the transformation step. Now, in the XML world, because they are absolutely determined to capture nothing but pure meaning, well, of course, you need to do some sort of post-processing to turn that into like an Adobe InDesign file that can be sent to the printers or an HTML document that can be fired off to a browser. But that idea of like expanding those placeholders into the final actual content or transforming something like a step in their multi-step instructions into an unordered list with some extra spans and maybe an image tag to go along with it. There's nothing wrong with turning that meaningful markup into browser-specific stuff as you go out. But the idea is that what people create and what you store isn't that final destination markup. And the final one is that you tailor the editing tools that people are given to the vocabulary of their content, not the vocabulary of a particular output format. And this, again, is where the WYSIWYG thing keeps coming back to bite us because what we almost always end up doing is like turning on more HTML tags in the WYSIWYG editor rather than saying, well, okay, what are you trying to do? What are you not able to do with this? Oh, you keep wanting to put in references to books that are listed on Amazon? Okay, well, we could put an Amazon book button in your WYSIWYG editor. Store a tag that just stores an Amazon product ID and we'll handle rendering it. Instead, we say, oh, well, okay, we'll give you links, we'll give you images, we'll let you float it left or float it right because you'll need to do that. And they end up cobbling together those things out of those HTML primitives. Everything I've described is wonderful and magical and full of wonderful unicorns. But I'm guessing that there, is everyone already just convinced? Should I just blow through this part? I know Larry isn't, just on principle. Larry can't agree with me on something, we have to battle it out. So I'll go forward. The first thing I wanna make clear is this is not some sort of pie-in-the-sky future scenario for us in the Drupal world and in the WebCMS world. This is an example of the, I think, token embed, token entity insert module. I can't remember, it has those three words, I can't remember the order they're in. It basically lets you use tokens, like bracket, embed, node, node ID, inside of the body of a content to do that sort of gallery embedding stuff we were talking about. And there's even a button in the WYSIWYG editor that lets you click, I want to embed a thing here. It handles making the token for you and everything. That's something that we already have, we're already using on production sites. That's actually what the MSNBC.com project uses to solve this particular problem. And it works well for them. There's issues with using tokens that I'll get to in a little bit, but that's very close to the kind of thing I'm talking about. This is, God help us, the Wikipedia edit box. Although it is by no stretch of the imagination beautiful. Although it is not a pretty editor. And it doesn't even really do any post processing to format it the way that it will look on a webpage. It's really raw text. It's still a good assistive editor because all of the buttons that are up there, all of the tools that it provides people who are editing text on Wikipedia aren't about HTML primitives. They're about the specific vocabulary of editing text on Wikipedia. So it's got drop downs for things like template placeholders for particular common bits of text that need to be entered on certain kinds of articles. It's got things for doing elaborate cross references between different kinds of documents. The stuff that matters on Wikipedia is what this tool accounts for. This, although it's a little bit washed out, is from a WordPress plugin called Post Snippets. It's basically like a macro tool for WordPress. You can define little short codes yourself, like in this one I'm defining FIG as a short code. And I can define any number of attributes that I can put on a FIG tag. And then I tell it what markup I want that expanded into when it's finally time to print the page. This is a very simple example, but I can say FIG, caption, text, and URL. And it will expand that into a fully captioned figure, caption, image file, stuff like that. It can be used for all kinds of stuff, but the idea is that the person entering things doesn't have to enter the whole structure. And this module then adds a one click button to insert that short code in the text that's being edited. This, although it's a little hard to make out, a little bit washed out, is actually the code from the media module for Drupal 8. This is currently in progress. It lives on GitHub, but it actually does work with the current alpha of Drupal 8. Basically, it allows you to insert markup like this. A div, it uses data attribute tags for HTML5 to say, this is an embedded node, it's node ID one, and I want the teaser view mode to be what's actually inserted. And while I'm at it, I also want a caption underneath that node. Now, this is interesting because this one isn't being handled by the media module. This is being handled by Drupal's built-in captioned image plugin for the, I'm sorry, for CKEdit. If any element has a data-caption attribute on it, Drupal is smart enough to use an input filter to expand it into a figure. Wrap the element in that and then put a fig caption tag underneath it with the caption. And because it's using standard HTML5 markup, stacking data attributes on to capture the meaning and the important information, the media module pulling in a node and rendering its teaser inside of the body, and the captioning tool, knowing that it should wrap it in a figure tag and then put the caption underneath it, both of those play nicely together, although they don't have any actual pre-existing knowledge of each other. They're both leveraging these tools and turning that very, very streamlined meaning markup into the full, complex markup. And the cool thing is, is if you actually go to the large page that has that embedded, in-place editing still works on the embedded node because it's still going through all of the normal Drupal rendering layers. If you embed node two on node one, you can go to node one and edit node two from it. Node exception. This is an example that I really love. It's a particular CK editor plug-in that for the math heads in the room, you can enter pure text markup. I know who likes math. Now, the thing is, if you actually gave someone HTML primitives to try to represent this stuff, it would be crap. They'd be wrapping stuff in spans, trying to figure out how to align things, size things or whatever. But it turns out there's already a language called text that most of the people who care about doing that already know. So this simply wraps something in a, hey, this is a chunk of text wrapper tag and renders it on output. What you store is text markup. What you get is wonderfully formatted stuff. Now, if you were really crazy, you could even do things like, you know, stuff that could be rendered into a 3D graph or something like that rather than simply do it in an equation. There are other libraries that let you actually do 3D rendering in the browser and you could, if you wanted to, build a layer that outputs stuff in that form too. But the key is that you're storing the meaning and making the decision later about how to output it. So how do we make this happen? I've got, I think, what, three minutes? We can totally cover this. So actually making it happen, it's already something that's going on. In bits and pieces here and there, we're solving this problem of islands of structure inside of the body field in ways that work. But ideally, we'd also get on the same page so that whenever we encounter one of these weird little islands of structure problem, we're solving it in the same way. So that just like the media embedding and the captioning stuff just working together because they're on the same page, all of our tools can do the same thing. The first one is, yes, build on top of HTML. Like it or not, we are a web publishing tool. We manage lots of different kinds of content. But for tools, for projects that Drupal is being used on, most of the time, the web is a pretty important component of it. And there's nothing wrong with building on top of HTML. The paragraph tag, the m tag and the link tag do not need to be reinvented. We don't need to go build a custom XML DTD from scratch before we give content editors a field to enter things into. The next one is to start using data attributes on the elements that are being entered into our content when there's stackable behaviors. Things that could apply to lots of different kinds of elements, but we want to capture them. The caption tag that applies to images or block quotes or code fragments and stuff like that is a great example. Other things that we've actually done for clients, although sadly we can't release it, NDAs, is an audience tag that we were able to add onto any element. It let us choose like a Drupal role that this particular snippet of text should be visible to. And in the WYSIWYG editor, it was just a matter of creating a plugin that added a span with a particular data attribute onto it. Let people select it, write the CSS so that inside of the editor, that text got special highlighting. But when it was actually output, a Drupal filter handled either removing it from the markup that was being shown or allowing it to stay there depending on the role of the viewer. That's a simple behavior that could be used almost anywhere in the markup, but once we'd implemented it, it stacked really nicely. And because we were doing it with standard HTML data attributes, it didn't collide with other things. The other one is start accepting that defining a custom element may make sense for self-contained things that are an important unit of content that goes in there. An example would be like a glossary term. I want to insert our company's 800 number right here in the text, but the 800 number differs from country to country. Or we need an icon next to it that indicates whether the call center is open or closed at the time that the person is viewing it. That's all stuff that's very easy if you're using those kinds of placeholders, but it's a huge, huge pain if you're expecting people to actually create special markup to enable those things every time they type the 800 number. And the final one is accept that this transformative step, turning the meaningful markup that we're adding into the final destination markup, that transformational step is not a sign that we haven't built a good enough WYSIWYG editor or we haven't given people powerful enough tools to edit it. That's a good sign. It means we're letting them edit what they need to and we're doing the hard work on output. The cool part is that there are lots and lots of options. Once we start using HTML5 standards, things like a Drupal filter can handle this post-processing of turning simplified meaning markup into final HTML output. In Symphony, there's crazy stuff like response handlers that can even intercept the fully rendered Drupal page before it actually goes out over the wire and you could run a single regular expression over the whole thing and replace lots of different stuff all in one fell swoop if you don't wanna use a Drupal filter. You can write jQuery plugins on the client side that pick up on particular data attributes or catch special tags that you've added in. Angular Directives, if anybody's been hearing about AngularJS, maybe you probably stumbled over AngularJS developers this week. Angular Directives are all built around this idea of defining the behavior that a particular data attribute should add onto something on the client side. You can also, if you're outputting things to via a content API or something like that, when meaning is captured in this way, it makes it much, much easier to map the meaning that's inherent in your content to however the destination handles that particular meaning, turning something into JSON or sending it over the wire to somebody who expects a very particular goofy XML format or something like that. Once you're determined to store the meaning rather than destination like a markup in HTML, mapping between formats gets way, way easier. So that's it. Store just the meaning in our markup. Tailor the quote whizzy wig tools to the vocabulary of the content that people are using rather than the HTML primitives that we think it's going to be rendered to and accept that there's always going to be a transformative step to render things into the final presentational form even if there's some HTML that's being entered into the body field. And what we get from that is it's a lot easier to build tools that match the vocabulary of an organization's content that makes actually editing the content easier for people who aren't HTML designers but instead are domain experts on what the heck is going on inside of their company. They understand that company's internal concept and what they deal with but they may not know how to turn that into an HTML design. It gives us cleaner integration with external systems that aren't necessarily HTML or aren't necessarily using the same designs that we've got. It actually makes whizzy wig implementation simpler because keying on known data attributes or catching custom tags that we're using to capture that meaning, it's a lot easier to write a whizzy wig editor plugin that keys on those things than one that actually tries to become like a little dream weaver in a box inside of the body field. And finally, it gives us a much easier way to do a smooth transition into future standards, things like web components and as AngularJS is taking off more and more and more, because we're capturing meaning and because we would be using things like HTML5 custom elements, HTML5 data attributes, we'd already be on the way to using the stuff that the future web is being built out of. That's all really cool stuff. That's all I've got here. There's a bunch of stuff that I've been like firehosing at you. The media project is actually a really good place to look at right now as Drupal 8 evolves. But again, these are techniques that aren't restricted to some crazy point in the future. These are stuff we can do now and we can improve the lives of our editors and we can improve our own lives as we have to deal with crazy, unpredictable design changes and stuff like that. It's great stuff, I think. That's all I've got. Thank you. It looks like we've still got like eight minutes or so until everybody turns into, I don't know. It's the last session of the day, so. It's the last day. Shoot, anybody who wants to hang out here and talk about semi-structured content, let's do it. No, I mean, are there any questions? Yeah, well recently, we're looking into alternatives to media modules since it's totally messed up all the time in the WYSIWYG. And we tried asset module, which has been around for a really long time and it was incredibly awesome and you can create different entity types and just put buttons for them in your WYSIWYG. Have you ever used that? I have not actually used that. I've mostly stuck with media module, but that sounds very interesting. It's incredibly awesome and it's like gorgeously designed and you can put captions on things and you can create just any fieldable entity and just shove it in your WYSIWYG and reuse them. Interesting. That is actually what the media in eight project is doing. It's got that entity embed module. But yeah, I mean, it's not so much that I'm I'm extremely like married to media module as the thing that must be used for this. I thought that media module, the Drupal 7 one was what the standard was and there must not be anything better out there because no one talks about it. Then I try asset and it's like. Yes, the two projects are actually collaborating on Drupal 8. So maybe that's where the combined awesomeness came from. Hello. Two questions. Well, one question, one comment. First question is short. It is tokens. I'm sorry. No, I mean, you mean, are tokens an option for this? Tokens was the question. I'll take liberties with the structure for that question. I'll just take it in. I'll take it where I want. Yes, tokens as an alternative to embedding lots of large swaths of structural markup. Tokens today are still a really good alternative to that. We're using them on the MSNBC project to do entity embedding inside of node bodies because, well, it's implemented and it works. It exists. It required zero code, just installation and configuration of the WYSIWYG editor. To be fair, configuration of the WYSIWYG editor today is probably what, like, a person year. Yeah, but I guess maybe to make the question better, like, what are maybe shortcomings of those? Oh, let me tell you about the shortcomings of tokens. One, that bracketed syntax makes it really easy to recognize when you're, like, staring at markup and saying, oh, that's a token right there. The problem is, is token is a string of colon-delimited bits. Like, this is an embed, it is a node, it is node one. Here is the caption for it. Also, you should float it left. The token API has no support for things like an optional parameter there. Or, say, a caption that includes a colon. Because it's colon-delimited. Would making those look more like HTML tags, is that duplicating HTML? Or is that because of a visual distinction is kind of nice? Well, I would say that the ideal is we create markup using HTML tags, data attributes, or even custom elements when it's justified. And assume that that's how it will be stored if we want to represent them differently. So people don't mess, so people don't confuse it. Then that's a perfectly legitimate use case for a WYSIWYG editor. Because the WYSIWYG editor can supply what that type of insertion placeholder should look like in the editor. And then do some other completely different thing on output. And that's where I like to think of a WYSIWYG editor's really, really proper role as being an assistive editor for the meaningful structure, not like an in-browser design tool. Right. OK, and the criticism part is the snuggard here? Oh, OK. Well, of course he is. I was having this conversation with him about Markdown. And about how he made the argument. If Markdown is an acceptable answer, then you don't have this problem. OK, sure, sure. But he was making the argument that, and this is just maybe a rebuttal to some of these points, but in the use case where you have people writing simple narrative content, Markdown is a solution. Yes. In these cases where you have very complicated narrative things, and this was his words I'm paraphrasing, but he said, those kinds of things, you will never be able to abstract to the point where we can essentially empower anyone to create that kind of National Geographic-looking layout in a node. And that if you want to do that as a publisher, you should hire someone who, you know, a hierarchy of authors, some of which you can do simple things, some of which you can do more complicated things. I concur. Yeah. I actually agree. And I'm going to toss you a pack of skittles for providing a perfect opening to something that I did not have time to put into my presentation directly. I'll get off the mic now. You've got a skittle, too. So just to sort of summarize that, the idea is because there is so much unpredictability and so much craziness that you could potentially try to jam into the body field, essentially it's like, just keep it as simple as possible and treat anything beyond like boom, article, as a special design challenge. I am not quite as fatalistic about that. I don't think that we can create just an arbitrarily flexible, structure-making thing. That's not what I'm necessarily saying, but rather I'm saying, in most organizations, there are lots of recurring patterns in the kinds of complex bits that get put in there. And identifying those and making provisions for them with custom tags and assistive tools and stuff like that gives the flexibility so that everything doesn't ultimately drift into being one of those one-off, give them a web designer because they need to write a news article kinds of scenarios. I think it was the Guardian, actually. I can't remember. It's either BBC or The Guardian. They put up a really interesting article on their account strategy Tumblr, go figure, about what they call data picks. The idea is it was this recurring thing they first did in an article about like Honeybee die-off. But it was a way of sort of doing an infographic, sort of doing a link, and sort of doing information. It was a photograph, a statistic, explanatory text, and a citation link all wrapped in sort of a collection. And they were just doing it as a one-off. They had a web designer go in because the person who was writing the story said, I really need some way to do this. And then the minute they did it, like they started getting requests, everybody wanted one of those in their articles. And after maybe a couple of weeks of getting lots and lots of requests, they broke that out. And they started treating it as a standardized piece of structure that could be done without any kind of manual design interference. And I think that's actually the really, really solid way forward. It's not so much that you plan everything else, plan everything out in some sort of giant content waterfall. But rather, when the special needs come up, you deal with them. But rather than just throwing HTML primitives at people and telling them to sort it out for themselves, you help them. And if it keeps being in need, you automate it. I think that's my standard answer on it. But I definitely recommend looking up the data picks article as an example of how that can be an organic process rather than just like a giant developer project where I think it's handed to an editor. Yes. Hi. Another potential solution to this problem, full disclosure, I'm working on a contrib module that implements this. But I'm curious to know your thoughts is to take those mini blobs and transform them into a series of mini chunks. So actually, this particular link, the way you design web content is changing, is all about that particular approach. And I think there are a lot of scenarios where that's really, really effective. The challenge is, if it's actually inside of a long piece of narrative text, it can really seriously disrupt the experience of actually editing and maintaining the narrative text itself. Because what you're doing is you're taking a story or an article and breaking it up into a bunch of really, really distinctly separate databasey chunks that are reassembled by a template. And it can be really good for things like product overview pages where you're essentially stacking different actual chunks. Here's the product description. I want a selling point about this particular feature, a selling point about this particular feature, call to action, and then details. And I want marketing people to be able to come in and rearrange those or swap something in the middle. But that's not quite the same. It's related. And that's actually one of the reasons that I put this link in the slides. I'll be pushing out the PDF. But I think that's a good solution for certain types of problems, but not quite the same thing for the pure narrative flow with embedded structure thing. Cool. Thanks. Oh, well. Brian Hirsch, White House web team, thank you so much for your thoughtful presentation. So we are in the process of trying to go responsive with WhiteHouse.gov. And my mind is racing now with what would it look like to make a WYSIWYG that stores meaning and later gets transformed. So here's a half-baked idea to add to the list of possible ways to. Those are the best kind. So I'd love to talk more with you at the bar or anyone else who's interested about ways to do this. So yesterday, I attended a great presentation on aesthetic, which is going to be included in Drupal 8. And that seems to me like it could be a compelling way to store something meaningful somewhere. I have no idea what aesthetic is. So aesthetic is going to be used in Drupal 8 for asset management. And so lower down in the stack than altering a fully rendered page in the symphony response, assets get grabbed by aesthetic. I really know very little about this. This is a very interesting one. It's a way of capturing. I want image blah and aesthetic handles. Oh, that's on an Amazon S3 bucket. Or oh, that's on your local Dev workstation while you're working on it locally or something like that. Yeah, but you can apply all kinds of things to transform it along the way. Yes. In the slide on different ways that transformational step can happen, response handlers in symphony are actually one of the ways that can do that. Initially, I was thinking that some of the things that I'm trying to get done here would require that approach in D8. But since then, there's actually been some improvements to the filtering system that make it one of several options we have for doing that transformation on the server. But yeah, I absolutely agree. And I think there's a lot of scenarios where an organization that has a lot of consistent needs like this that are going to be applied to a lot of pages, it might actually be more efficient to build something like aesthetic that they just pipe everything through rather than trying to go in and monkey around with all of their input filters and implement it in that way. So the last quick comment, the thing that strikes me is potentially compelling about aesthetic rather than the filtering system in Drupal is that aesthetic, the meaning that we're describing is generic, right? It's not tightly coupled to Drupal logic. There's nothing note-y about it or entity-y about it. So to collaborate with a project like aesthetic and make it a generic plug-in that can be used outside of Drupal also. Yeah, that's, and especially in larger organizations that face this problem a lot, they are likely to face the same transformation needs in things other than Drupal-based websites. So anyways that we can standardize that stuff, whether it's web components or a standardized server-side tool that does that handling, yeah, that's big thumbs up. Thanks. So I'm gonna give you a nice little softball. Ha-ha. So anyone who's dealt with clients has had the conversation of, no, structured content, it's a thing. You're not doing Dreamweaver in the browser. Yeah. And they say, no, but we want Dreamweaver. Or rather, Microsoft Word. Yeah, I need flexibility. I don't get the structure thing. Yeah, and the conversation with... And flexibility is assembly language. Yeah. And I think that's a good point. Yeah, and I've had the conversation with three-quarters of the clients that we've dealt with, at least. And only some of them I'm able to convince because the others aren't listening. This is how most of our Twitter arguments start. This is gonna be good. So now we're adding another layer where we have chunks, blobs, structures within blobs. Those structures could be defined inline or referenced to a chunk or blob elsewhere. This poses an enormous usability problem for the content editor, even assuming that you've been able to structure things from the developers, leaving aside the developer challenges of building this, which are surmountable or smart, for editors, the potential for inconsistency in the UI or in predictability in the UI is enormous when you have at least four different levels at which you could be thinking about what it is I'm typing where. We have all those levels today. We just only implement two of them. I guess, I mean, yes, the answer is if we do a bad job on UI design, the editorial experience will suffer. But I think, at least in my experience, across a bunch of websites, that's not something that we escape by not doing this. I'm not suggesting we don't. Right. I'm just saying, how do we sell it? How do we plan ahead? How do we kill it? You've got a node edit form. You've got the body field in it. You've got this button that gives you a pop-up within it that may be referencing something else or maybe something you edit inline. And sometimes you'll want one, sometimes you want the other, teaching the content editors when they're gonna be using which one and explaining to them why, in this use case, it makes sense to do this of those five options and this one and that and making that predictable. That poses an enormous UX challenge. I would say that's our job. I'm not gonna disagree with you. I'm just saying that's a challenge that should not be overlooked. No, I don't think it should be overlooked. But, right. I mean, yes, that was in the background, someone was saying that's the same problem that clients face with the print process. And we've seen that same transition was responsive design with designers who've come in from a print background and aren't familiar or comfortable with the idea of making design systems that adapt. I think it goes, it's a step beyond that because it's more people who have to deal with more levels of question as they're entering content. I would say that ideally they would face fewer questions because the affordances they're offered in the UI correspond to the tasks they're being asked to perform rather than them being given HTML primitives and told to translate those to the tasks they're being asked to perform. And mapping those things correctly is our job in the same way that figuring out what fields we're gonna break out and what we're just gonna allow in the body field as part of the modeling process, figuring out that like, oh, hey, they need to get recipes slapped into these articles all the time, so we're going to make that something that there's a provision for rather than simply giving them a style guide and a bunch of HTML buttons. That's the kind of shift that I'm talking about not necessarily like some sort of ideological mission to get XML in there or something. It's because this approach allows us to simplify the problem space that they're presented with rather than expanding it. Then I'll give you the question that expects someone to ask. If we build these wonderful body field semi-structural editing things, client asks, okay, so why do I have any fields on my node other than the body? What's your answer? For supporting assets that don't need to actually live at a particular place in there, for metadata that may not actually appear as part of the body field, there's a number of reasons why having a separate box on the input form is actually beneficial to editors. A prompt for a file upload is different than just a giant bin. I mean, some people may be perfectly happy with just a giant bin and supporting tools that do structure in there. But again, it's like, you know, that's the way the XML document-oriented community does content editing, and we don't have to hire job developers to sort things. So there's a benefit to having a database to go along with that. Microphone. Oh, microphone. While he's coming up to the mic, is there a, oh, Donna. Oh, it is like Donna Hugh. Can we assume our content editors know about the content they're creating and not assume their morons? Well, that's a tough nut right there. But again, even assuming that a content editor is literally coming in fresh off the street, knows nothing about the business, knows nothing about HTML, I think that if the affordances we provide to them correspond to the business and what its needs are to the content that they're expected to produce rather than being HTML, primitives that they're expected to build that content out of, I still think we're closer and the training challenge is at least simpler than what we have today. I only had one quick thing to interject in. That's that my experience with content editors is that you can give them a node or content edit screen that's a mile and a half long and they will be fine with it as long as it meets their needs and has everything that they're after. Yes, that's been my experience too. The problem is never, this is so long, rather it's, this isn't what I'm trying to do. There's all these fields that don't correspond to what I care about and that actually matters way more. I think I'm gonna ask maybe the flip side of the question that Larry asked. So in Drupal we have, so in Drupal we have NAB types and fields and a field UI and- God bless them all. And so, you can make different view modes and configure exactly how you want something to look as a teaser versus another thing and then you can build views off of all that. And just to interject, the media module that embeds entities inside of other entities, one of the things that it ships with is an embedded display mode. So you can even set up a display mode for when this entity is embedded somewhere else, it doesn't just have to be the teaser, I can explicitly say what an embedded version looks like. So that, I think that ties in. Yes, so, you know, so DITA's great because it has this concept where you can build task lists. For some values are great, yes. It'll also, to be fair, DITA's namespace includes something like I think two or 300 basic tag types. So it's complicated. So I think a lot of use cases could be solved with build out node bundles, build out field collection bundles, build views. If you really need a custom entity type, that's not well represented with a node or a field collection, build a custom entity type, and then bundles off of that. And if you need that stuff to live inside of narrative flow, then you embed via media or whatever, you embed an entity, you embed a field that's on the same node that you're on, or you embed a view. And in that world, the concept of an entity or the concept of a node becomes sort of like a manifest for a particular piece of content. It's narratives that it has, supporting elements that it has, whether it's references or media elements, and stuff like that, yeah. So the question is, what do you see as a use case for then building a special like WYSIWYG plugin that captures like some kind of DITA meaning in something that's not an entity or a field collection? In example, like one of the examples I fall back on is I wrote an article for a blog that had a very specific house style for how citations of articles elsewhere were supposed to be created. They didn't just want a link off of the off there, they wanted the actual originally published title, they wanted the URL, they wanted the author's name, they wanted a date, and they wanted it inside of a particular span structure so that their current design could do some special handling of that that they wanted. That's not like, that didn't correspond to any particular tag, like a site tag or something like that. And they hadn't broken that out into like separate fields or something, they just wanted when you referred to an external site in some way, all of that stuff got captured. And it was a huge pain. And it was just on the side of, does it really make sense to like make that a separate field and then have an embed code for that? That in my opinion might be a useful case where creating like a house style tag where you've just got attributes that you dump all those things into. There's a WYSIWYG editor the same way we have a link editor in the WYSIWYG tool. And then it gets exploded into whatever structural markup they need. That's the kind of scenario where I think it could be justifiable. But in Drupal we have so many tools that are disposable to actually break structured things out into separate little pieces and then insert them. But I think that sort of embedding of a field or embedding of an individual entity is probably gonna be one of the things that we lean on a lot. Okay, cool. And cause I think for a lot of organizations especially like small and medium sized ones, they're not gonna wanna like be like, oh I need to hire someone to build me a custom CK editor plugin for my version of a task list when they already have Drupal tools that let them. And in addition like that post snippets tool for WordPress, it let you actually define some of those sort of house style expansion macros and stuff like that using just, using an admin page. And I think that kind of approach could probably handle a lot of those weird middle ground cases while still enforcing standard structures. So we're really not like Drupal is not really all that far from doing this. No, no that's the thing. It's like the answer is actually way simpler than describing the problem accurately. Thank you. I don't know but it's fantastic. So I'm just wondering with your token insert solution. Say I'm trying to do something as simple as enter like an image float right. It's got a caption. It's got some fields. I don't want them to junk it up. So I want it fielded. Is this the kind of thing like, is that gonna be an entity in and of itself? Or is that a field collection? That's the kind of stuff that the media team is heatedly debating right now. But like in D8 just in the core, you know, Drupal 8 core, the way it ships, the image like icon in the WYSIWYG editor is not just a standard CK plugin. It's actually a Drupal specific insert an image WYSIWYG editor plugin that does things like captioning the data attributes and when you say float left, float right or center, it's not adding custom alignment attributes. It's actually adding a data attribute that a filter post processes into that so that if it needs to change based on other needs. I mean, Drupal core is already even doing some of that for simple solutions like that. So on more complex solutions like a slide show, like on your MSNBC site, what's the user experience like when they're creating that? Like it's just literally like an ad slide show. Yeah. So they're not like having to go like, oh crap, I gotta go make my slide show first so I can do my token. Well, yeah. Right now they do have to create the slide show first. But that was more of a timeline question than a is it possible question. There's already a couple of different tools in the Drupal space that like when you're creating something that's being referenced on node A, you can go into a sub page and create node B before it gets referenced. And that I think is just, it's been done, it's just the meat and potatoes work of, you know, wiring all the parts together on a particular project. Okay, thank you. So I guess I was under the mistaken impression that you might be talking also about RDFA and schema.org and how that relates to the structuring of data in the body field. You didn't really touch on that at all. No. It's really cool that we, that, you know, you know, sort of adopting, you know, or if not adopting, you sort of emulating certain standards. I want to be clear. I'm not suggesting we adopted it in Drupal. There's a lot we can learn from it. Right, yeah, exactly. Emulate or learning from standards. But, you know, but it seems to me that, you know, that sort of leads towards creating, you know, another sort of taxonomy of meaning through our markup where we have this great taxonomy of meaning from schema.org and why don't we, you know, use that also for this purpose. I mean, it can do two things. It can do the, it can serve the purpose of, you know, of describing things to external machines, right? Yeah. But it can also serve the purpose, couldn't it? I mean, I posed the question, couldn't it also serve the purpose of adding this level of meaning, you know, internally for the reuse of these things and the structuring of them? Yeah, I mean, I don't think those things are incompatible at all. But the idea that what I'm hoping we can get away from is the idea that what we actually put in the body field while editing and persist to disk, you know, or memory if you're using MariaDB or if you decide you want to save your nodes to Memcache because you're insane or something like that. You know, what's actually persisted does not have to have a one-to-one correlation with the actual output format. And if using RDFA information at the content level captures the meaning that your editors need to capture, then I would say that's perfectly reasonable and perfectly fine to use because ideally the specifics of what's being marked up underneath it could be transparent to someone who's using a WYSIWYG editor to actually do the input. The challenge is when the tools that they're being asked to use to input it aren't actually corresponding, well, to the kinds of content meaning they're trying to encode. Does that make sense? It does make sense. It does make sense. I'm just concerned about the, you know, that, you know, we already have been working hard at, you know, well, not me, but, you know, SCORE and all the people who work hard on this stuff. The Royal WYSIWYG. Have been working hard. I haven't worked on anything. I just make presentations, so. But, you know, other people are working really hard on getting, you know, on getting good usability around getting, you know, getting RDFA into our, you know, our markup and getting it linked to schema.org. So there's a level of meaning there already. And if we want to use that level of meaning for other things, why add this other taxonomy, you know, stuff? Well, I mean, that's a good question. Like, for example, an author bio being inserted at the bottom of an article or something like that. RDFA, at least my understanding of it, it's been a while since I've looked at it. It's a means of communicating the meaning of random markup to machines on the other side so that they can figure out what your actual intent in this blob of markup actually is. From a content perspective, that whole blob of markup might not even be what I deal with. I may have just like the equivalent of like a token insertion type thing that says, insert user 52's bio here. And that tag that I'm using at the editing, in the editing interface, may never actually even be reflected in the final markup that, say, a crawler sees. It may be expanded into the markup but it includes RDFA tags and stuff like that. Right, but schema gives us things like bio and type of author and date and all kinds of, that gives us all kinds of actual taxonomies for describing these things. Yes. I mean, I guess in situations where the vocabulary that's being provided by like schema.org has a one-to-one correlation with what's being entered in by an actual editor, then I would say by all means it makes sense to leverage that rather than going off and inventing our own custom tag type or something like that. But I like to think of this as being more in line with things like the W3C standards on web components and stuff like that where, well, I don't wanna insert a video, I wanna insert a photo gallery or something like that. Rather than trying to wrangle a pile of markup or something like that, you would create a gallery tag, include the information that's necessary to be passed along to that web component and have it expanded there. Which, but that web component may expand it into things that use RDFA tags on the individual elements, like who is the person who took this photo? What is the copyright on this photo and stuff like that? It could absolutely be used but one of the advantages is that can be handled purely programmatically on the templating system and stuff like that even if the editing interface is as simple as gallery four needs to go here. Oh yeah, that makes a lot of sense. Cool. Hello. In a project that I worked recently, we have this issue that you described that there are so many images, galleries and things that need to go in this exact place and we have the whole discussion about WCWIC and our solution and I would like to know your thoughts about that was getting rid of it at all. So what we did, in the content types, we defined so many like pieces, fields, individual fields for so many things where for the thing that needed to be dynamic, what we did was like a dynamic body which actually was entity reference of pins and we created a whole set of pins where for example, we needed a tutor to show some tutors. So that being only accepted the tutor handle and then in the back end, we make these transformations and present them as needed or if we need paragraph, we need captions, we need images loaded to the left or right that those are things that were defined like in the specific pins and in a body where you are editing, you just like add or reference those pins and then the whole thing gets built. So that's what our solution, but that worked great when testing but when we came out to move to production, we have to import like 20,000 articles and for each paragraph, we had a beam and imagine like images, sliders and the whole thing. So we ended up like with 50,000 beams. We needed to hook, implement, to that for the block page broke. Yeah, no, I mean, and that's, I think that was sort of touches on what was mentioned in one of the earlier questions, that idea of like stacking reusable blocks and assembling pages out of them. It can be really useful, but when you find yourself in those situations where we've just got a pile of text and things need to live in them, it can also mean that whatever entity you're breaking those pieces of text into, suddenly you're just buried in them and that's one of the reasons that I like to see whether or not like, you know, an example might be, you know, tokens to embed a particular beam inside of the flow of text rather than actually breaking up all of the text into individual beams. So like it's just text for the stuff that's just text, but insert a Twitter feed stream right here or something like that can be handled using entities. And one thing that these allowed us, and it was in your slides that this, we see with things break mobile styles. Since we're using beam, we were able to define for this beam, how does it look like in the desktop version and in the mobile version? Yeah, it lets you like encapsulate the responsive rules in the element. So, I mean, that was really helpful, but when, you know, when it's like in production, and it's working, I mean, it's solved our problem, but it introduces so many things that we needed to take care of later than, I mean, maybe if we have like a go-to solution that would be really, you know, better. Yeah, well, thank you. So, help me out on this one. Should I be proud of you or disappointed in you that you have yet to use the word Transclusion? Well, yeah, Transclusion. We call it embedding. Technically, in the community of people who use words like Transclusion casually, this is Transclusion. It's taking a particular thing and including it inside of another thing via the use of some sort of tag or something like that, yeah. And actual question. So, one of the things you said- We're also like 630, so anyone who feels the need to go and get a beer is welcome to. I'm just gonna be here until they cut the power, I think. You mentioned earlier that slapping classes on div elements is not actually a content definition mechanism. And I'm not gonna disagree with that. But at what point do you say the same thing about slapping data attributes on a div is also not a data definition? Data attributes are at least namespaced. You can have multiple ones of them to include data from different sources, whereas classes are really just a giant pile that everyone stacks stuff into. So, theoretically, the same problem is there, but you at least have the advantage of like, you can define the data attribute that you need and populate it, not worry about whether or not you're colliding with someone else's class or whatever random class the designer who is working on the front end style sheet happened to use. You're less likely to fight through the theme or otherwise it's the same problem. It at the very least kicks it down the can until we're all defining data attributes and there's dozens and dozens of those on a single element. It could happen, but it's better. So what would be your guideline for when slapping a data attribute on a div is sufficient versus defining your own custom elements mechanism thing? Well, I know in some cases where people are just using data attributes regardless and just saying we use divs. And I think that works today, but like the rule of thumb that I think I put in there was data attributes are good for things that stack. Like a thing that is captioned gets this data attribute rather than wrapping something in a custom caption tag or something like that. You can then apply the captioning behavior to images, galleries, embedded nodes, whatever. Whereas an individual freestanding thing itself like this is an embedded gallery. I would never put galeriness onto a paragraph because by definition that paragraph would then become a gallery. You would want to instead use the gallery tag inside of or between two paragraphs or something like that. That's the rule of thumb that I tend to go towards, but like this kind of question is the philosophical stuff that the XML and Dita communities like because they live in the world of markup, but they need good solid meaningful structure. Like this is what they consider the work of content modeling. When we think of it as what should be a field? What should be a type? They're thinking about those questions in terms of markup structures. And like that's the kind of stuff that we can at least look at how they deal with those kinds of questions when we try to figure it out. Cause they've been spending 20 years on it. Well, isn't the transclusion notion the lowercase token, if you will, lowercase t? Yeah, it's a bucketing mechanism where you can bring in content of some type and display it. And whether it's an image with fields or some other kind of content. Holding just the token seems the right way to do it to me because it's at runtime that you have to do things like check for licensing or, I mean, all these other issues that come up in enterprise content management, but our normal run of the mail things too, like putting an image in content area. It just seems like that, that seems to be the way forward to solve putting in almost any kind of content. Putting a thing in a thing. We should probably use that technique. Right, and then the classes would be the things that would be applied by the editor in order to do things like say, I want this paragraph to be an intro or I want this paragraph to split into two columns on a wider screen. That's to bring the editorial design into the editorial content structure. It seems like we have these things. The media module is not quite robust enough too. Yeah, and I don't think that media module, I think media module is an example of this technique being used effectively, not the tool by which this technique will be applied in all cases. And there's some things that I don't think need to live inside of the markup flow. Like on the MSNBC project, one of the things they wanted to do was editors, when creating a news story, had to be able to choose what should lead that story. A video, a still image, a poll quote from the story that they thought was particularly snappy. It was all the same content type, but one of the things that they chose, one of the metadata fields that they selected was what should the emphasis on this story be, like photo, quote, whatever. And that allowed them to sort of pass design-ish kinds of decisions towards, like was that design? Because it was still like the templating and the design system that handled what leading with the quote actually turns into, but they were still making those decisions. And I think that's, it's always gonna be a fuzzy sort of line between what is design and what is meaning decision, but there's a lot of room for improvement before we run into the pure platonic form of design and meaning separation, I think. That'll never happen. Ah. Okay, one more question. So if anyone's done imports of other content that used to be some sort of version of HTML. Hell is other people's markup. Yeah. It's particularly challenging. You have to go through, if there were any images that were embedded, is this a remote image that I can just keep there, or do I have to import this? I mean, but even with tokens, right? It's also very much pain in the ass to kind of, all right, this is node ID four, at least we're using migrate module. And to be clear, media module also lets you use UU IDs, the actual unique identifier rather than just node IDs. So like they're at least putting some thought into that kind of stuff. And like glossary text insertion and things like that. When we did do that for a client, we used machine names on those things, not IDs because saying insert the 800 number here is easier than insert glossary item 59. Just from a parsing perspective, if anybody else ever has to deal with that markup. And then I think panelizer has gone pretty far with IPE and panelizer. Obviously that doesn't get stored back into the body, which can be good and bad. But I think having that kind of functionality, we could bring some of those components over and just kind of apply that to the body instead of just applying it to, with the idea of having you little widgets that you can kind of pull into the body. Yeah, and I think like the framework that CK Editor gives us in CK Editor 4 and Drupal 8 especially where the configuration is a lot more cleanly integrated. CK Editor is like widgets system that allows you to have sort of a self-contained chunk inside of the WYSIWY Editor that gets its own code for manipulation and can have its own helper dialogues and stuff like that. I think that has the potential to be a really big tool in this for us to sort of like sandbox a kind of complexity behind an embed tag or a very short specialized piece of structure and then give people a useful interface to manipulate that. That kind of leads into my question. Do you really think WYSIWYGs are up to this? Because in my experience even anything above the, even the most simple things, lists and tables, they still muck that stuff up. Do you really think they're up to this kind of complexity that we're asking for? I think they're more up to this than they are reproducing the functionality of Dreamweaver. You know, I think there was just an article that went up on Medium. Medium.com has an amazingly like just super streamlined, ultra minimalist inline WYSIWYG Editor. If you have permission to edit a document, you can just click in it and start typing and select text and format it. There's no barrier between the concept of a thing you're viewing and a thing you're editing if you have permission. And the lead engineer on their WYSIWYG Editor just wrote this long tirade on how incredibly horrifyingly terrible the content editable interface in the HTML spec is and what that, just the whole idea is broken and all the stuff that has to be worked around. I mean, writing a useful WYSIWYG Editor that lives in the browser is a non-trivial task and I would never wish it on anyone. That I mean, God bless the CK team. Well, that's what I'm looking at. So you, in your opinion, CK Editor is the best tool if we wanted to try and implement some of what you're talking about. I personally think so. Having talked with the CK team, their thinking is very much in line with this stuff in terms of like capturing meaning wherever possible, presenting a useful editing interface for that meaning and then transforming on output. They're definitely on board with that concept and they've built APIs to support that kind of stuff in their plugin architecture. Thank you. Not a question. Ha, ha, ha, crafty. Yes, I work in a Ditta shop, actually. Woo! I know, and we have a tool that we use for the Ditta editors called OxygenXML and which has an author mode which is a gooey mode and our authors are, you know, electrical engineers. They're subject matter experts. Yes. Not CMS experts. But you would think that they would appreciate structure. Well, I'm not saying that content authors appreciate structure. Right. Because the stuff that they design is modular, right? They have a piece of digital logic that does this. I'm gonna hook it up with this and it sits inside. But they fight tooth and nail because they just wanna write. Yeah. Like a word processor. But no one downstream can benefit if it's just words. Yeah. Paragraphs. So we've had to get sneaky with them by using all kinds of things like Schematron and XPath. So you can say, it looks at the content and says if what they've done so far, right, matches this pattern, then offer up these things as content completion wizards like you have in a code editor. It looks like you're writing installation instructions. Ha, ha, ha, ha. But it's underneath, underneath it's structured. Yes. But do you, it looks. Do you even know how to get any Clippy's voice? It looks. Ha, ha, ha. It looks like you're trying to write installation instructions. I have falsetto too. It's about as close as I can get to an answer more on paperclip, but yeah. So it's how to keep structure while not encumbering them with the structure. And like the idea of a WYSIWYG editor where you use buttons to do this, that is currently the predominant mechanism for capturing meaning. And I think that that kind of stuff, if there are predictable enough things that you can recognize, that's a really, really cool approach to it. But at the end of the day, you wanna make sure that you're storing structure that captures meaning. Even if from their experience, it's just well I started writing this thing and oh okay cool, it was helpful for me. You know, that's the ideal case. But we also can't just magically do that until we figure out what the structures are that they're gonna be inputting and what we want the destinations to be. Wait a minute. Yeah. Now I just wanted to follow up. This is just turning into a bath. It's a core conversation. That's fair. And you did say that everyone can go to beer if they want to, right? It's true. So I don't know what you people are doing here. Now I just wanted to follow up on the sort of WYSIWYG CK editor question and answer there is, you know, the history of Drupal 8 development has been a lot about, you know, how can Drupal collaborate with other projects? We've heard a lot about that. Done some great work in terms of the collaboration between Drupal and Symphony. But another area where that's happened is between Drupal 8 and CK editor. So the process, you know, we've been wanting a WYSIWYG editor in Drupal core for years. But they were also terrible. They were also terrible. And in the process of trying to get into Drupal 8, you know, like CK editor did a great job in their early releases of version four. And then since they released 4.0 to now where I think they're on 4.4 or 4.5 or something like that, that's involved like over a year, maybe a year to two years of really close collaboration between the CK team and a lot of Drupal developers. And one of the things that we actually talked about in Prague, which I think would just be the craziest thing ever, is CK editor even has like the kind of stuff that you would normally say, oh well when somebody pastes HTML from Microsoft Word and you know, we want to scrub it into something clean, well they've abstracted that step into a separate component of the CK editor framework. So you could do things like paste markdown in and it turns it into whatever you want the underlying markup to be. Or say you could write a plugin that recognizes you are pasting a YouTube embed code and turns it into a media module embed code. Stuff like that is all possible. And that's that idea of like providing the assistive layer on top of the underlying structure. Yeah, so I think it's a really great example of like you were mentioning, you know, like the did-it people have figured out all sorts of interesting stuff, but meanwhile we in Drupal have figured out all sorts of interesting stuff and wouldn't it be cool to collaborate and CK editor is an example where that's happened, where the CK team has been into the WYSIWYG world and figuring out how do you put a WYSIWYG editing into a browser and spend 10 years, you know, figuring that out. Meanwhile in Drupal, we've done a lot of thinking on content structuring. So the last two years of the two teams actually working together to create a WYSIWYG editor that supports content structuring has really paid off. Yeah, I mean as a WYSIWYG skeptic for a long, long time, I'm learning more and more about that and getting and at least watching some of those conversations unfold has been really encouraging because like the CK team in particular is really on board with the idea of building an assistive editor in the browser rather than, you know, a Dreamweaver box and that makes me happy.