[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Stage One Proposal: Change the specialization base of imagemap
My
argument against putting imagemap in the base is that it is a little-used element and the actual design of it may not be ideal (one could think of other ways to associate linkable regions with images). Adding it to the base would add element types that few
DITA users ever use a privilege a particular design where the current design is not privileged (because use of any domain is never mandatory).
I
don't think "quality of the implementation" and "taxonomic position" should be influencing each other quite that much; it's not hard to argue that the specification and implementation of <image> isn't what it ought to be, for example. If <imagemap> is meant
to be a universal functionality (if out of completeness rather than widespread need), I would think it belongs in base. If it's meant (once <sort-order> is out of there) to be the initial part of a "we could write an image module and deal with the recursive
can of worms around images and multi-channel publishing", sure, it belongs in a domain.
<title>
in <imagemap> is likely the simplest thing but I suspect it doesn't solve the problem; the problem sounded like it's a combination of "I want imagemap in fig so I get all the fig-associated processing I already have" and "how do I associate a title with <imagemap>";
adding title to the imagemap element's content model fixes the second of those, but not the first.
Graydon Saunders | Publishing Solutions Developer | Precision
Content
Unlock the Knowledge in Your Enterpriseâ
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Eliot Kimber <ekimber@contrext.com>
Sent: 09 July 2019 15:55 To: dita@lists.oasis-open.org Subject: Re: [dita] Stage One Proposal: Change the specialization base of imagemap My argument against putting imagemap in the base is that it is a little-used element and the actual design of it may not be ideal (one could think of other ways to associate linkable regions with images). Adding it to the base would add
element types that few DITA users ever use a privilege a particular design where the current design is not privileged (because use of any domain is never mandatory).
I also like the idea of simply allowing <title> within imagemap--that might be the simplest solution to meeting Zoe's original requirement. I think it's more appropriate as a standalone domain, even if it's a very simple one. I think it's easier to justify adding sort-as to the base since it's clearly a fundamental facility that some languages (Japanese, Traditional Chinese) must use for almost any lexical ordering situation and other languages often have need for. Cheers, E. -- Eliot Kimber http://contrext.com ïOn 7/9/19, 3:23 PM, "Kristen James Eberlein" <dita@lists.oasis-open.org on behalf of kris@eberleinconsulting.com> wrote: So we have two possibilities here: * Add <imagemap> and its child elements to base -- also <sort-as> * Change the specialization base for <imagemap> and area to <div> Which makes most sense? Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com <http://www.eberleinconsulting.com> +1 919 622-1501; kriseberlein (skype) On 7/9/2019 3:14 PM, Eliot Kimber wrote: [I sent this to Zoe yesterday but had intended to send to the main list] ï<div> should be the best choice but would need to think it through: <imagemap> allows <image> and <area> <area> is currently a specialization of <figgroup>. <figgroup> is essentially the semantic equivalent to <div> so it would make sense to also make <area> a specialization of <div>. <div> allows all the elements from which the subelements of <area> are specialized, so that works. One way to evaluate a specialization design is to generalize it back to the base types and verify that the result is still valid. If it is, then the specialization meets that requirement. So using <div> for <imagemap> and <area> definitely passes that test. Then the other question is whether or not the specialization is semantically consistent with the base, which is a more subjective question. But in this case, <div> has no semantic beyond "container" so hard not to be semantically consistent with it. Ditto for <area> specialized from <div>. Cheers, E. -- Eliot Kimber http://contrext.com ïOn 7/8/19, 8:30 PM, "Zoe Lawson" <dita@lists.oasis-open.org on behalf of zoelawson17@hotmail.com> <mailto:dita@lists.oasis-open.orgonbehalfofzoelawson17@hotmail.com> wrote: Originally, <imagemap> was a specialization of <fig>. This means you cannot use an <imagemap> directly inside of a <fig>, which makes it complicated to add a title to your image. You can work around this by using a <div> inside of the <fig>, but that seems like an extra layer of complexity. If we change the specialization base of <imagemap> from <fig> to something slightly more generic such as <div>, that may simplify the adding of a title (or other content) around an <imagemap> in a <fig>. I would like some technical assistance determining which element makes the most sense to specialize from. Thanks, Zoà Lawson --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]