-
-
Notifications
You must be signed in to change notification settings - Fork 384
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
Provide a shortcut for typing character markup #4462
Comments
The |
Btw, i have code that could be adapted to make this work. |
Hi @r12a. Having some example code would be good if you've done such thing before. I'm not sure if there's some API we can use or do we need to maintain a list of all the characters (to convert |
@sidvishnoi The code i use for my own pages may help. Note, however, that my code has some differences, built in to the way i use it. These include:
But there's probably a good deal of the algorithm that's useful. Search for the
Not quite sure what you mean here. If you simply want to get a list of the characters in the textContent, that's easy, use the ... operator (eg. Don't know whether that helps. Let me know. |
Note that i just changed one of the links in the previous comment. |
We likely want to go with the approach we use in I'll try to find some time this month. PRs welcome to respec-web-services as well as ReSpec - having either will help us move forward. |
Hello @sidvishnoi . The i18n WG is asking me whether we are able to make progress on this. The full markup is now described in https://www.w3.org/StyleSheets/TR/2021/README.html#unicode-codepoints |
@r12a Not at the moment from my side, sorry. I'll have to get free from my daily job (or time-off) to focus on this. Happy to review any pull requests related to this though. |
@sidvishnoi i'm just checking whether you are likely to have time to look at this again? Cheers. |
@r12a not at the moment unfortunately. Maybe in March as my current work contract ends then. |
@sidvishnoi ping ? |
I'll try after next Thursday... Sorry to keep you hanging. |
Thanks @sidvishnoi . I can't really create any PR, but there's a link to my code, fwiw, above. I also have a (new) list of class names that i use to manage the output at https://r12a.github.io/scripts/template/xx.html#template_codepoints – this may well be far more than we need for W3C docs, but i point to it for what value it may have. I think the key thing is to be able to go from |
Here's the plan:
Images
|
I have, indeed, and i update the file as soon as each new Unicode release occurs (it's needed for my own tools, such as UniView). We can decide how to manage updates later. There are a couple of choices.
I originally used char and hex class names, but it slowed down the content authoring, so i switched to ch and hx. That makes it much faster to type the code (esp. in DreamWeaver, where i just type I'm not sure why you suggest nobdi. I can't think of a situation where you'd not want to have bdi. (It's harmless when not needed.) Not sure what you mean by supporting graphemes, but it's absolutely important to allow a sequence of characters rather than just a single character – eg.
It's a lot of typing and it's not portable (For example, I'm likely to want to copy (a lot of) stuff between my own stuff and the i18n lreq docs), so i prefer the span & classname approach.
They are very useful, though – especially when talking about invisible or ambiguous Unicode characters, so i'd encourage you to support them out of the gate if you can. Of course I understand that my own setup is a lot simpler and more efficient than what we'd implement for respec. Not least because the images (aiui) would need to packaged in the same directory as a document that is being published, to pass publication rules. So my assumption was that WGs would make or find images for use here, and store them locally. (I don't mind if people copy images from my set on GH, but i wouldn't expect documents to pull images from that location.) That said, i think it is important for people to be able to include images in the document, rather than only characters – especially for ambiguous or invisible characters. (The i18n WG already does this in some of their documents.) hope that helps |
Btw, the other class name values, such as |
Oh, and if |
Agreed. This is a strong argument for using classes over custom element.
This is my concern. Consider Support for images for control/invisible characters is reasonable. That's something we can definitely support out of box in first pass.
With all these classes and special features, I wonder if it would make sense for ReSpec to support it. How about we provide a backend API (via respec.org), and then i18n specs can use a custom preProcess or postProcess plugin to handle this specific logic? My concern being all these classes is they're are tied to unicode expansion plugin, but being classes they're "too global". This is why I was looking to encapsulate it with custom element. But I guess we can take these classes into account only with
I think if we host images on W3C/Unicode servers, pubrules can be modified to allow those URL prefixes. Storing images locally is fine too - I'm hoping we can make a page at W3C or Unicode servers (or even respec.org in worst case) to support that. |
Yes, that's what i would expect to happen (both points).
There are a few problems here with hosting images:
In principle, yes, but bear in mind that this is really aimed at single characters or small numbers of characters. Otherwise the following Unicode names grow very long. When i want to show full words i will typically create a figure or another mechanism which hides the character names but allows you to discover them, if needed.
No. That would be a vast collection. I'm proposing that the WG creates or sources just the images it needs, but that the respec authoring would allow them to easily show those images with attached Unicode names. |
Seems like |
@sidvishnoi The I18N WG has been waiting on this feature for ~1 year now. I was actioned with writing to follow up on when this might make an appearance or how we can help with implementation. Can you ping back with an estimate? |
Hi, sorry for the long wait. I've started work on it just today finally. I think we should be able to get a working version within 2-3 weeks, as I try to find time from my regular job - please remember I'm a volunteer here. I'm not sure about the images part yet, but the invisible characters ones should be there in initial version.
|
@sidvishnoi Thank you so much! We appreciate your working on this--we understand about the volunteer aspect. |
Is your feature request related to a problem? Please describe.
The i18n WG is developing recommendations for referring to one or more characters in markup (see https://w3c.github.io/bp-i18n-specdev/#char_ref_template).
The most basic template for the expanded markup is:
This is not complicated, but it's a bit lengthy and fiddly for authors to type in full, especially if a sequence of characters is involved. We'd therefore like to propose a macro that can be used with respec docs to automatically create the full markup from a more concise base.
Describe the solution you'd like
We propose the following expansions, where
lang
attribute is strongly recommended, and has a BCP47 language code as its valueclass="hx"
, and the latter usingclass="ch"
Examples:
[1]
OR
--->
[2]
OR
--->
It may also be useful to have a way of indicating that no bdi element is wanted (although much of the time an image would be useful as a replacement). Maybe something like:
For invisible characters or tricky to display characters (such as certain combining marks), more complete solution would allow for an image in the expanded markup. For example:
If it's possible to standardise or accept user input wrt the image location, this could be achieved with a shorthand such as the following, where an additional class name of
img
orsvg
is used.(Btw, I can provide a set of images for invisible characters, eg.
.)
Additional context
Note that there is intentionally no span between
</bdi><span>
. The gap will be provided by styling (which avoids problems with variable space widths and makes it possible to reduce the gap or change it at scale if needed).The text was updated successfully, but these errors were encountered: