-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image #14
Comments
I've created 1. version of draft for that feature. Feel free to comment on it. |
I was wondering if we should ever go with My question doesn't take into consideration things like emoticons which may technically require inline images but are not part of the "Image" feature. |
I was also thinking about it and there is even a trace of it in draft:
However not all images could be marked as |
That's the point of the recommendation. I don't think we're here to propose the adoption of "decorative" images. The whole scope of the project is driving developers to have editor installations for the creation of quality content. |
Ok, that example was unfortunate, but besides that
There is also nice example of image that is a part of content, but can't be treated as <p>This case centered on some sort of "intellectual property"
infringement related to a comic (see Exhibit A). The suit started
after a trailer ending with these words:
<blockquote>
<img src="promblem-packed-action.png" alt="ROUGH COPY! Promblem-Packed Action!">
</blockquote> So even in quality content there can be place for inline images (but I must admit that this use case is much rarer). On the other hand, |
@Comandeer: Strange example... if I'm not wrong, When it comes to the "Widget" thing... it makes sense (unsure about the name). After all |
Taken directly from HTML5 spec ;)
No, you're not wrong, but you miss very important quirk:
So technically speaking, it's
IMO it is, as the end of sentence is denoted by dot. In this example we have colon informing that the next part of the sentence is some kind of enumeration or pointing explicitly to something.
And that's the point why
|
Ok, I think that we could drop the ability to insert inline images and stick to the much stricter version of the draft, which allows only |
I agree. If Inline Images would be necessary, we could (and should) see them as a different feature, with different scope, semantics and implementation details. I don't see them as necessary though. |
I totally agree about inline images being a totally different feature. We've been analysing this for CKEditor 5 in context of the awful issues we had with images in CKEditor 4 where image can change its type from block to inline and back. We agreed that inline images are unnecessary unless you want something like smileys, inline equations, etc, but these are all separate features. Only sometimes you want to have a real inline image but this can be an opt-in feature of an editor. |
However, one thing worries me in the spec – the |
I think you're wrong. From the spec (bolds mine):
|
So this is outdated: https://www.w3.org/TR/html-markup/figure.html?
|
But it says the same as the spec - you have even quoted that!
|
Errr... sorry :P. |
I'm thinking of one more addition to the draft… Probably we will use
Maybe we can add to the draft that |
I like this proposal a lot. ++1 from me. |
+1. Otherwise all this cannot be styled (CSS FTW!). |
Ok, I've added fragment about that class attribute. |
I'm not sure about that. How the image should be sent to the client is CMS's responsibility. The editor's responsibility is to allow inserting the image into the content. If that image stores a reference to an image entity in that CMS, then that CMS can render the image correctly, specifying the right sizes and URLs. It would also be very hard to imagine how it would need to work from the user perspective. The user would not have a chance to understand the UI which asks about things that the editor would need to create a responsive image. Hence, for me it's strictly CMS's responsibility. |
I agree that it would be difficult (and pointless) to come with "variations" on the spec. We should stick with a single recommendation for it and leave such variations to integrators. I agree with @Reinmar that a serious responsive feature would not be part of the editor itself, but of the system it is embedded within. |
Hm, at the moment we have a small note in "Implementation concerns" about that and it uses "SHOULD" keyword. Maybe switching to "MAY" will be enough? Or just drop it completely? Art direction cases could be possibly handled by the UI to select different images for "mobile", "tablet" and "desktop", but more sophisticated cases aren't so easy to solve. |
Maybe the point is... do we really want to be the ones saying how to do this thing right? |
Is there anyone who does it actually? :D But yeah, pretty good point. Responsive images are so difficult to be done right that probably it would do no harm if we drop that part of the spec completely. |
Ok, info about responsiveness is dropped. |
Ok, it seems like a stable feature. I propose moving it from draft to the recommendation status. I'll wait 3 days for objections and then do what should be done ;) |
The first multimedia issue here ;)
Today images are as important as text itself (or even more important in some cases), therefore we should implement that feature in the most semantic way possible.
The necessary starting point is
img
HTML element with:[src]
attribute that points to image,[alt]
attribute that provides appropriate textual alternative.But there is also a matter of responsive images. Really good WYSIWYM/WYSIWYG content editor should be prepared to handle such cases. It can be handled by:
[srcset]
attribute onimg
elementpicture
element.I think that including support for responsive images should be one of fundamental "features" of that Feature.
The text was updated successfully, but these errors were encountered: