2012-10-01 Alt and Title support for Images (irc Chat)

based on -- http://drupal.org/node/1553094

01:35 HyperGlide: anyone free to discuss -- http://drupal.org/node/1553094
01:35 Druplicon: http://drupal.org/node/1553094 => Alt and Title support for Images => File entity (fieldable files), Code, major, needs work, 98 comments, 30 IRC mentions
01:57 RobW: HyperGlide, What were you looking to discuss about the Alt issue? Current code or method/approach?
01:58 HyperGlide: RobW: i am not a coder... so more the method and approach that has been used. recent comments and trying to build consensus on how best to solve for the needs.
02:00 RobW: HyperGlide, Cool.
02:00 RobW: HyperGlide, What's your current opinion?
02:00 HyperGlide: RobW: follow the thread?
02:01 RobW: I have some of my own, trying to reconcile the work that has been done with the way I think alt/title should function.
02:01 HyperGlide: seems that the current solution that was at RTBC was creating new tables for the data.. a recent comment reported that there are core tables that should be the location the data is stored.
02:01 robeano|afk is now known as robeano
02:01 RobW: HyperGlide, totally, I'm in there a bit.
02:02 HyperGlide: RobW: see ya in there ---
02:02 HyperGlide: http://drupal.org/node/1553094#comment-6518100
02:02 Druplicon: http://drupal.org/node/1553094 => Alt and Title support for Images => File entity (fieldable files), Code, major, needs work, 98 comments, 31 IRC mentions
02:02 HyperGlide: I would think that because media is not just 'images' having its own table offers value.. but uncertain.
02:02 RobW: HyperGlide, Wait, I thought the RBTC was using token support?
02:03 RobW: what comment is the database table patch?
02:04 HyperGlide: RobW: the rtbc used tokens.. but the data had to come from some place.
02:04 HyperGlide: let me look for that.
02:04 RobW: HyperGlide, Ok, wait, we're on the same page.
02:04 RobW: HyperGlide, Yeah, the tables are from file entity fields.
02:04 HyperGlide: the discussion at hand is where to store the alt/title data when a user adds it to a field.
02:05 HyperGlide: correct
02:05 RobW: So the main reason it wouldn't be a good idea to use the image table is that images in D8 are gone, and file entity is in core.
02:05 HyperGlide: jamesbenison had expressed to use the core tables.
02:05 HyperGlide: RobW: that is a pretty dam good reason.
02:05 HyperGlide: RobW: you working on D8 core?
02:07 RobW: Also, image module doesn't allow re-use of images, so it is basically the same idea -- a one time use table. I believe it's technically part of the field, which also references the file, as opposed to file entities that are structured differently, with a field referencing a file entity with fields on it.
02:08 RobW: HyperGlide, Not really, but I keep tabs and participate in some of the issues. I'm trying to fix up some D7 modules before I start on any D8 contrib.
02:09 HyperGlide: so in short the current patches offer a more flexible way forward. and not as noted in #95
02:09 RobW: Yeah, 95 doesn't have the whole picture.
02:09 HyperGlide: RobW:  can I use your notes here in a reply on the thread? i do hope davereid and co and commit this.
02:10 RobW: Sure, haha, they maybe should be cleaned up a little.
02:10 RobW: Might be best to double check everything before you post it.
02:10 HyperGlide: writing now and will post here for commit..
02:10 RobW: The main issues I have with alt + title are twofold:
02:11 HyperGlide: comment *
02:11 HyperGlide: do you think the patches as written are RTBC?
02:12 RobW: I haven't tested it, so no comment.
02:13 RobW: OK, my issues:
02:13 RobW: 1. Great, we have tokens. But alt without context is shit. The alt needs to be different for each context the media is embedded in, or it is as useless as not having an alt at all. See my comment in #23 and related issues.
02:14 RobW: 2. Title is useless. People love it because they've been using it and it's a tradition, but it really is unreliable for almost everything. My comment #57, and linked issues.
02:14 HyperGlide: RobW: read and agree. but the module can't create the alt text for the site.. right? In my eyes the content creators need to take responsibility for that.
02:15 RobW: Right now it does. I believe it autopopulates with a "file name" token.
02:15 HyperGlide: more for your no. 1 on our site we strongly use the alt text and put great effort in to add it.. but without this patch we have nothing showing.
02:16 HyperGlide: I believe there is no "default" in these patch as noted by tsvenson remarks and issue -- http://drupal.org/node/1792334
02:16 Druplicon: http://drupal.org/node/1792334 => Prepopulate alt/title attribute configuration with the default field tokens => File entity (fieldable files), Code, normal, postponed, 6 comments, 1 IRC mention
02:16 RobW: To fix the alt issue there needs to be either database fields that are attached to the node like with image, or a hacky workaround where the alt has a revision table with different revisions per context inserted to.
02:17 tsvenson: Who woke me up here? :)
02:17 RobW: HyperGlide, Well you would only be able to add alt text once as the patch is, which would kill either subsiquent insert alt text applicabilty, or reuse of media.
02:18 HyperGlide: I believe that we should have a way to add alt to the media element. and if no alt is provided let it be empty. it is not the best ux but some sites having alt for media 2.x is better than none.
02:18 RobW: I think the token integration is great, but it's not a solution for alt text, and never should have been.
02:18 RobW: Right, right now it's better than nothing, and works fine if you're only using the media once.
02:19 HyperGlide: RobW:  I think the token issue is side from this patch.  as it is not working. but your other point about if you use the media more than once is something I did not observe in my testing.
02:20 RobW: But if you use the media more than once you only have one alt for various contexts. IMO that's unacceptable, and if a key feature of Media is reuse of file entities, then this is not a fix for adding alt.
02:21 tsvenson: RobW: I agree it is rather odd to add to fields that does nothing other than store thing is the database. That's why I changed status to "meeds work" in http://drupal.org/node/1553094#comment-6508544. But not to block the patch from commit I then added a postponed follow up issue as suggested.
02:21 Druplicon: http://drupal.org/node/1553094 => Alt and Title support for Images => File entity (fieldable files), Code, major, needs work, 98 comments, 32 IRC mentions
02:21 rootatwc has left IRC (Ping timeout: 256 seconds)
02:21 HyperGlide: RobW: reading yoru links on the http://dev.w3.org/html5/alt-techniques/#secm7
02:21 HyperGlide: tsvenson: hello
02:22 RobW: Well the tokens are what drives the suggested fix for alt. Field + token is what was talked about up to #30 or so.
02:22 HyperGlide: seems there are 2 issues here .. 1 default values for alt tags -- using tokens or empty.. 2 -- ability to add more that 1 alt tag for each fid
02:22 tsvenson: RobW HyperGlide: I am though a little curious to know why prepopulating the output with the known field tokens would be such a hard thing to add in the main patch. Just have a bad feeling that my follow up patch will take time to happen. I'm not able to code it myself...
02:24 tsvenson: I think on problem can be that for those tokens to work the contrib token module is required and that would mean another dependency. Or is there one for token for File Entity already?
02:24 RobW: tsvenson, Prepopulating should be easy, it's just not a great fix for the alt problem. A single field, whether populated by token or hand isn't going to work for acessability or SEO if the media is used in multiple places.
02:25 tsvenson: HyperGlide: Yeah, but the default value for those tags should not be anything other than the two fields the patch also add. Anything else would just be very wrong and confusing.
02:25 HyperGlide: RobW: i think that is the main issue -- does the solution need to support 1 media with mutliple alt tags per use?
02:26 RobW: tsvenson, "Default should be that the alt/title tokens are populating the configuration and thus outputted without requiring the user to manually configure it." I think that's exactly the way that it shouldn't go. Alts are part of content, not something linked to the file entity.
02:26 RobW: HyperGlide, Yeah. My opinion is yes, absolutely.
02:26 HyperGlide: tsvenson: for us -- we would not want to use default values but require each content creator to accurately describe the image.
02:26 tsvenson: RobW: Exactly, that's why, in my opinion, those field tokens are the only valid prepopulating choice. That since the output will be alt/title="" if nothing is entered in the fields.
02:27 RobW: Which I think is backed up by every a11y person and seo concious sitebuilder.
02:27 RobW: HyperGlide, EXACTLY.
02:27 RobW: great way of saying it.
02:28 RobW: tsvenson, I'm into tokens providing sensible defaults, if that's what the site demands.
02:28 tsvenson: HyperGlide: But that is exactly what you get here as those two added field are exactly for typing in the proper alt/title texts. Now they do nothing.
02:29 HyperGlide: RobW: that said.. as you noted the current pates is a 1 to 1.. not 1 to any where used unique alt.. so can you comment on the complexity to adjust this patch to a 1 to any where used unique alt.
02:29 tsvenson: RobW: Sure, but in this case these two tokens are simply copying the values from the alt/title fields to the display formatter fields, nothing else.
02:29 RobW: tsvenson, But in any site I build I think the better usability would be to make each content editor consider what the photo is in context and add it manually. Different styles maybe, but I think my method would result in better content.
02:30 HyperGlide: for the tokens.. tsvenson you are not talking about populating the user field.. but populating the display settings?
02:30 RobW: HyperGlide, I see two ways of making that happen. I think I mentioned them in a comment back a couple mins, let me find.
02:31 HyperGlide: RobW:  okay. ty
02:31 RobW: "To fix the alt issue there needs to be either database fields that are attached to the node like with image, or a hacky workaround where the alt has a revision table with different revisions per context inserted to."
02:32 HyperGlide: RobW: got that ;-)
02:32 HyperGlide: from a coding point of view. how complex is it?
02:32 tsvenson: RobW: But that's exactly how this work. You have the two alt and title fields for images and you enter the text in there. With this patch they will be present when you edit files of the image type. But, nothing will be outputed for those attributes as there is no link between those fields and the rendered output by default.
02:32 RobW: HyperGlide, I don't think "attached to the node" is quite right, but they're part of a field that is only used on eplace on the site.
02:33 HyperGlide: RobW: understand your meaning i believe. link to the FID and NID it is being used on.
02:34 fatguylaughing has joined (~fatguylau@65.64.83.127)
02:34 HyperGlide: tsvenson: I think I understand your point better now. you are expressing without the tokens -- the data the content creators write will not be written into the HTML. they are just helpers to ensure the site builders do not forget a critical step of module configuration?
02:34 rootatwc has joined (~paris@dsl-n9d3ha.dyn.edudsl.gr)
02:35 RobW: tsvenson, Really? Well there needs to be a formatter for media images that uses those two fields. That's not really my problem though, my issue is the 1 to 1 relationship with file entity and alt, which doesn't match up to the 1 to 1 to many relationship of alt to context to file entity in a context.
02:36 HyperGlide: RobW: would how would you feel about this condition. user 1 loads a new piece of media and tags it with an alt.  another user comes along and wants to use the same media on a second piece of content. Should the alt field for user 2 be empty of have the existing value from what user 1 wrote?
02:37 tsvenson: HyperGlide: Yes, those two fields, alt and title, the patch adds to the manage fields tab for files of the type image is doing nothing but store any text filled in them into the database. That's all. Then the patch also adds a display formatter for images for the alt/title attributes. But since those fields are empty by default the html output will always be 'alt="" title=""' out-of-the-box.
02:37 HyperGlide: tsvenson: understand a bit better. apologies for missing that earlier.
02:37 RobW: tsvenson, after reading your comment in #80 something, what you mean is that it works great right now, there just isn't a token added to the file formatter by default?
02:38 tsvenson: HyperGlide: To get it linked, the sitebuilder will have to go in and enter the field tokens for those two alt and title fields in the corresponding display formatter field.
02:38 HyperGlide: tsvenson: yep undertand.. this is as you noted a site builder ux.. and makes ther work a bit faster and less likely to skip a critical step.
02:39 tsvenson: RobW: Exactly, just apply the patch, upload a few images and input some text in the alt/title fields. Nothing gets outputed in the HTML, then just add those field tokens to the display formatters and it magically starts working.
02:39 HyperGlide: adding that code for the tokens to be in the display formatters is not hard if i recall RobW words above. but the tokens must match the correct alt based on the other concerns discussed here.
02:39 RobW: tsvenson, What about with the "open file entity dialog after uploading content" issue? wouldn't the content editor see the fields then and be able to add whatever they like to alt and title at the time of upload/insertion?
02:40 tsvenson: RobW: Yes, with this patch there will be alt/title fields when you hit the edit button in for example the media field on a node for an uploaded image.
02:40 zirafa has left IRC (Read error: Connection reset by peer)
02:40 HyperGlide: RobW: yes they would see. .but then the data gest into the db.. but when the page renders the db data is not getting into the html becasue the display formatter is not completely configured out of the box.
02:41 HyperGlide: tsvenson: did i get that correct?
02:41 RobW: HyperGlide, default tokens aren't configured. If the user wants to add some non-token content, they could.
02:41 tsvenson: Thing is, we will get tons of support issues about this, Just look how many that miss adding the convert placeholder text for the text format after adding the media button for WYSIWYG. Despite the red warning about it...
02:42 RobW: Or if they wanted to add the tokens then, they could I believe. Right/wrong?
02:42 tsvenson: HyperGlide: yes
02:42 HyperGlide: understna now
02:43 HyperGlide: RobW: i agree with tsvenson having the tokens makes life easier and prevents a whole bunch of support request in the media que for people that dont RTFM. the tokens are NOT for creating the alt value. .only to support rendering in the HTML.
02:43 RobW: HyperGlide, tsvenson, My point is we should ignore the whole issue of default tokens until the method of adding alts per context is figured out.
02:43 HyperGlide: RobW: agree++++
02:44 RobW: HyperGlide, tsvenson AHHHHH, I seeeeeeee.
02:44 RobW: So you would add a token for the alt field to display as the alt in the media formatter setup?
02:44 HyperGlide: yep
02:45 RobW: I was under the impression that you would add a token to the alt field to specify another piece of content, like file title, as a default.
02:45 tsvenson: RobW: Yes, these are not core tokens like filename or other irrelevant one so unless users enter irrelevant text in the alt/title fields it will be great accessibility.
02:46 HyperGlide: I can write up a summary of all this in the issue que and make a task list of things that need to be done.. but i am not a coder. .not yet ;-)
02:46 tsvenson: RobW: Nooooooooo, we don't want that. then we get mgifford biting us :)
02:46 HyperGlide: tsvenson: do you agree with RobW about the need for 1 alt tag for each use of the media?
02:47 HyperGlide: RobW: did you see my question above about when media is reused? not sure i saw an answer
02:47 RobW: It seems rediculous that there is even a token config for that. It should be default, and could be accomplished without tokens. The whole token thing is completely superfluous to the alt/title issue,
02:48 RobW: HyperGlide, The question about methods of implimentation?
02:48 becw_ has joined (~becw@108-207-101-54.lightspeed.cicril.sbcglobal.net)
02:48 becw has left IRC (Disconnected by services)
02:48 becw_ is now known as becw
02:48 HyperGlide: RobW: no this one -- RobW: would how would you feel about this condition. user 1 loads a new piece of media and tags it with an alt.  another user comes along and wants to use the same media on a second piece of content. Should the alt field for user 2 be empty of have the existing value from what user 1 wrote?
02:49 tsvenson: HyperGlide: I agree that there is a need for users to be able to create custom alt/title texts for the context the image is used in yes. Unfortunately that is difficult to solve in File Entity. For wysiwyg embeds that can be done already as the alt/title attributes are part of the place holder code. For the media field it will have to be overridden by the media module I suppose.
02:49 RobW: HyperGlide, Right, that's site preference I think. I would prefer empty, but others in the thread have already complained about "lazy" content editors.
02:50 tsvenson: HyperGlide RobW. However, since the display formatters uses tokens, then the site builder are free to change those to whatever text/tokens they want and thus have full flexibility. Default will simply just use the texts from the image file type.
02:52 HyperGlide: tsvenson:  your last remark worries me that this solution creates whole new set of issues -- perhaps why no one wanted to address it this way ;-) -- Unfortunately that is difficult to solve in File Entity. For wysiwyg embeds that can be done already as the alt/title attributes are part of the place holder code. For the media field it will have to be overridden by the media module I suppose. -- does this mean another patch will be required f
02:52 HyperGlide: or the media 2.x branch as well to support this feature?
02:52 tsvenson: RobW: This isn't about lazy content editors at all since they have no control over the configuration. It is however a sitebuilding usability problem if it isn't working out-of-the-box.
02:52 RobW: tsvenson, Talking about a different comment, should the Alt field be filled by default on hypothetical second insert.
02:52 tsvenson: RobW: Then the sitebuilder will assume something is broken, not that something that looks like it should work isn't correctly configured by defailt.
02:54 tsvenson: HyperGlide: No other patch is needed. The media field is not part of File Entity, its part of the Media module that build ontop of the File Entity.
02:54 RobW: tsvenson, HyperGlide, I see two options. Multiple alt should be part of file entity if file entity is responsible for images in D8 and there is the possibility of re-use with file entity or Media module.
02:55 dalkire has left ()
02:55 RobW: tsvenson, I think we're talking about two different things now. HyperGlide, multiple alts will probably need to be a new issue, and definitely a new patch.
02:55 HyperGlide: tsvenson: understand.
02:56 tsvenson: RobW: You mean when you reuse an existing image and embed it in wysiwyg? In my book the embed should by default use any alt/title text stored for that image yes. Then you can use the wysiwyg editors image dialog to edit it, or the source code if you prefer that.
02:57 HyperGlide: RobW: Is not multiple alts. is yor case where each use as it's own stored value for the alt.
02:57 RobW: tsvenson, I think that's bad usability and doesn't cover all possible use cases. There should be a universal way to add alt and title, not one in one context (WYSIWYG), and one in another (file field). What if I insert an image with a file field on three different node types?
02:58 RobW: HyperGlide, Yes.
02:58 tsvenson: RobW: I think having multiple alt/title field in file entity will be very complex and confusing. It would be the same as having multiple title fields for every node...
02:58 robeano is now known as sparklesss
02:58 sparklesss is now known as spppparkles
03:00 RobW: tsvenson, I have a picture of a dog. In one node that is entiled "defenition of dogs" I embed it and give it the alt "A german shepherd". In another node titled "what I did this summer with my dog Poochy" I re-use the image. In this context the alt should be "My best friend Poochy"
03:00 RobW: A single alt ruins search/seo and accessability in this situation.
03:01 HyperGlide: listening....
03:01 RobW: I don't think there needs to be an extra alt field on the file entity per context to solve this. That would be very confusing.
03:01 tsvenson: RobW: Yes I would like to have that as well, but since the media field is added bu the Media module, it needs to add the logic for making it possible to override the default alt/title text for an image. What if the image has another author and you don't have the right to edit it. Or if the author (owner) don't want you to be able to write a custom text? Its a lot of different use cases here.
03:02 RobW: But there needs to be a way of storing alts per context that they're embedded in. Or else people who need alts won't be able to use Drupal.
03:02 HyperGlide: it is possible media is used more than 1x in just 1 node.
03:02 RobW: Those are both edge cases compared to proper alt handling, IMO.
03:03 RobW: The alt doens't have to be attached to the file entity necessarily. It could be attached to the file field.
03:03 tsvenson: RobW: Thing is that it is not just the alt/title filed you have that need for. What if you add a description field to the file. Then you have a need to be able to override that to.
03:03 RobW: tsvenson, Yep.
03:04 RobW: A caption field. So there needs to be an abstracted way of dealing with this.
03:04 RobW: tsvenson, What is the "media field" you're mentioning?
03:05 HyperGlide: tsvenson: thought the media field was depreciated?
03:05 tsvenson: RobW: Exactly. So the need of being able to override reusable content is not limited to just alt/title. Its virtually for everything reusable and thus needs to have a standard way of doing it in Drupal.
03:05 RobW: tsvenson, Agreed.
03:05 tsvenson: RobW: When you add a file field for your node and set the widget to media browser.
03:06 RobW: tsvenson, That would be a file field with the media browser. Media field is a deprecated field from 1.x. I understand you now, just wanted to get our definitions straight.
03:09 tsvenson: RobW: Ahh, OK. Yeah that old crappy field is still causing us trouble even after we depricated it. I think Media field is a good description of a field with the Media browser widget. Media browser field just sounds weird :)
03:09 RobW: So the questions here are 1. Is re-use of files tied only to the Media module and browser? A) If not, fields attached to context need to be taken care of by file entity. B) If so, should fields attached to context be taken care of by Media or File Entity?
03:10 RobW: tsvenson, How about file field with media browser? That's probably best to avoid misunderstanding.
03:11 spppparkles is now known as robeano
03:11 tsvenson: RobW: too long to write, need to save my finger tips...
03:11 HyperGlide: tsvenson: FFwMB is how we describe it --- F
03:11 RobW: FFwMB FTW
03:11 HyperGlide: RobW: ;-D
03:12 RobW: Back to my q above, I think the answer to 1B is File Entity which provides File field, because most likely the work will need to be done in file field.
03:12 tsvenson: RobW: How about we just call it media field and add old or deprecated when we talk about the 1.x one. After all, how often will that really come up in a discussion about media other than support?
03:13 RobW: tsvenson, I'll understand if you say Media field, but others might not.
03:14 RobW: Ahh, ok, I think I need to get back to work. Good talking to you all, I think I have a better understanding of what's happening here.
03:14 tsvenson: RobW: Thing is, we know we can just get thus far with file support in File Entity and especially what we can get ready for inclusion in D8. I think this is a good compromise really. The problems we are talking about here are all Media related.
03:14 RobW: HyperGlide, Was your idea to write something up based on this convo?
03:15 HyperGlide: tsvenson: compromise is limit to 1 for now?
03:15 HyperGlide: RobW: yes.
03:15 RobW: tsvenson, I think what's been done so far is great, I just think there is more to go. Without multiple alt support D8 will be broken.
03:15 tsvenson: There is for example nothing that prevents a site builder from creating their own field collection with a file field and alt/title fields whose tokens then can be used in the display formatters and viola you have context aware alt/title texts.
03:16 RobW: No gov't organization with a11y requirements will be able to use Drupal.
03:16 HyperGlide: RobW: can we commit this? and build or this patch will create more issues then it fixes?
03:16 RobW: tsvenson, that's not a fix, that's a workaround.
03:16 tsvenson: Also, since Media will still be a contrib module for D8, proper overriding is something that can be added to it then.
03:17 RobW: HyperGlide, the patches now should be committed, for sure. But multiple alts is another issue bug, not a feature request.
03:17 tsvenson: RobW: No its not at all since File Entity isn't dependent on the Media module and it will be perfectly doable to build that with just core plus ECK or field collection.
03:17 RobW: tsvenson, I hear you that this could be handled in Media, because without media there will be no way to re-use content. As long as that stays true, I see your point, and agree.
03:18 HyperGlide: RobW: okay. will move this back to RTBC -- with the wrietup and explanation. suggest next steps with the 1) unique alt per use 2) tokens for display formatters.
03:19 RobW: But, I think traditionally file field and media go hand in hand, so I think it's important to consider now.
03:19 tsvenson: RobW: Also wrong, you have file field sources and IMCE for example that allows for reusing of files.
03:19 RobW: Files or file entity?
03:19 RobW: \file entities
03:20 tsvenson wonder how many bowls of popcorn davereid and others in the audience have gone through watching the alt/title drama unfold...
03:20 RobW: The problem only occurs if you're re-using file entities. If you're creating a new file entity per context, all is good.
03:20 HyperGlide: tsvenson+++
03:20 RobW: IMCE reuses files I believe, not sure about file field sources.
03:20 HyperGlide: RobW+++
03:22 RobW: HyperGlide, I would say Unique alts per context should have its own issue, and tsvenson's issue regarding the default token is already up.
03:22 tsvenson: RobW: Yes, File Entity isn't needed for reusability of files, but it does add lots of goodies. Media will be just one of many options for both D7 and D8. Same as you have panels, context, display suite and others doing the same thing...
03:22 RobW: It's currently someone arguing something close to my point though ;). I think we might need a meta issue to collect all of these.
03:23 RobW: tsvenson, Right, the question is re-use of *file entities*, not files. That's where the current alt solution breaks down.
03:23 HyperGlide: RobW: agree -- will put cross issue links to them. so this one can be closed and committed. i do hope that davereid and others ready to commit.
03:23 tsvenson: RobW: http://drupal.org/project/filefield_sources was the module for D6 that first cracked the re-usability nut. It is available for D7 too.
03:25 tsvenson: RobW: Together with http://drupal.org/project/insert it made the best usability combo possible for D6 and D7 before File Entity/Media.
03:27 HyperGlide: Will look to put a summary on the issue very soon.
03:27 HyperGlide: thank you all for the discussion.
03:28 RobW: Another thing to look at is WYSIWYG fields module being vetted to replace the media button in D8 media and spark, in which case the edit inserted shortcode workaround gets killed...
03:28 tsvenson: RobW: Yes, so the core file entity (FE) comes with alt/title fields. you can then build a custom field collection that allows you to reuse existing images on a node and that has its own alt/title fields. Those could by default have the FE tokens and the display formater in turn has the new custom ones. Thus if you are OK with the core text, leave the tokens, if not, then just delete them and add your own text.
03:28 RobW: HyperGlide, No problem. Do I have permission to edit and add to your issue summary when it's finished?
03:29 RobW: tsvenson, That's a good workaround, but I think alts should be handled in some way out of the box.
03:29 RobW: OK all, I am out.
03:29 RobW: HyperGlide++
03:29 RobW: tsvenson++
03:30 HyperGlide: RobW: i do not think so... want to see a draft before I post? can create a google doc.
03:30 RobW is now known as RobW|workin
03:30 RobW|workin: HyperGlide, Are you doing this on your own blog or the issue queue?
03:31 RobW|workin: If the issue queue I can edit, I just didn't want to uninvited.
03:31 tsvenson: RobW|workin: Yeah, I agree it is a workaround and things could be done better. For now though I think we have to accept it and fix it right after D8. It is an elegant workaround though :)
03:31 HyperGlide: issue queue... and guess you are a d.o. admin...
03:31 HyperGlide: i also would like to put a copy of this chat in a patebin-- any objections?
03:32 RobW|workin has left IRC (Read error: Connection reset by peer)
03:32 tsvenson: RobW|workin: Re issue summaries, you can edit any issue summary on d.o, even for core issues. No special permission needed as far as I know...
03:32 RobW|workin has joined (~RobW@c-71-199-121-96.hsd1.pa.comcast.net)
03:32 tsvenson: RobW|workin: Re issue summaries, you can edit any issue summary on d.o, even for core issues. No special permission needed as far as I know...
03:33 RobW|workin: whoops, got kicked. HyperGlide, please, pastebin for posterity!
03:33 HyperGlide: will do
03:33 HyperGlide: 330 am here -- off to sleep.
03:40 davereid has been super busy today, but watching the conversation and going to re-read later today. having up to date issue summaries is always good too.
03:48 moshe_work has left IRC (Remote host closed the connection)
03:48 moshe_work has joined (moshe_work@nat/acquia/x-kbtwjfuuealkxhqy)
03:50 moshe_work has left IRC (Read error: Connection reset by peer)
03:59 CrashTest_ has left IRC (Read error: Connection reset by peer)
04:01 moshe_work has joined (moshe_work@nat/acquia/x-wkvwhelvbybhzjzv)
04:03 CrashTest_ has joined (~CrashTest@173-160-154-50-Washington.hfc.comcastbusiness.net)
04:06 tsvenson: davereid: Just make some popcorn before you start reading...