Changing the font-size attribute in XHTML tags through XSLT - xhtml

I have some XHTML that looks like this
<span style="font-size:8px;"><font size="3"><strong style="font-size:14pt;">EXAM: </strong>Head</font></span>
And I want to remove all font-size attributes so that it looks like this
<strong>EXAM: </strong>Head
I tried
<xsl:template match="font size">
<xsl:copy>
<xsl:copy-of select="#*" />
<xsl:apply-templates select="node()" />
</xsl:copy>
</xsl:template>
But that removes the whole node. Any suggestions?

A template with match="font size" should not be matching anything at all, but the template you show should copy the element it matches and all of that element's attributes, as well as processing all of the element's child nodes. So if the template you show is in fact firing, it should not be removing any nodes at all from the input. I infer that either what you pasted is not an accurate reflection of the code you are running, or else that you are misinterpreting the behavior you're observing.
You say you want to "remove all font-size attributes", which I take to mean all style attributes whose sole function in life is to carry a font-size property. In your sample output, however, you have also removed the span and font elements. I guess the example should be believed.
If I understand the problem correctly, you want a transformation that is mostly an identity transform, but which changes three things.
First you want to suppress style attributes if all they contain is a font-size setting. This is not actually easy to do reliably in the general case without writing a CSS parser in your XSLT, but let's assume you can get by with a simpler test: if a style attribute begins with a font-size setting, it dies.
If you're using a normal identity transform like the one given in the XSLT 1.0 spec, your transform already has a rule to process attributes. We want to override it for this set of style attributes, which we want to suppress entirely. Write:
<xsl:template match="#style[starts-with(.,'font-size')]"/>
Second, you want to suppress span elements which carry style attributes which begin with font-size settings. (Actually, a smarter test might also check for the absence of a 'class' attribute and other things; I'll leave that as an exercise for the reader.) Here you don't want to suppress the content, but you don't want the element in the output. So the content of the template is just a call to apply-templates:
<xsl:template match="xh:span
[starts-with(#style,'font-size')]">
<xsl:apply-templates/>
</xsl:template>
Finally, you want to do the same thing with font elements: process their contents, but drop the element itself:
<xsl:template match="xh:font">
<xsl:apply-templates/>
</xsl:template>
An identity transform augmented with these three templates correctly transforms an XHTML document containing your input to a similar XHTML document containing your output but with other things left intact.

Related

:root vs html - which is faster?

I have a CSS stylesheet that contains a lot of declarations starting with html.some-class. Now I'm wondering if there would be any difference if I wrote :root.some-class.
I suppose that the browser may scan the whole DOM to try to apply the html.some-class rule, because there might be an invalid document with more than one <html> tag. On the other hand, in a valid HTML document (and I can be sure that the styled document is standard-compliant) there is only one root element, so that the :root search doesn't have to traverse the whole tree.
Taking the above into consideration, would my stylesheet be more efficiently applied if I used :root instead of html?
Footnote: I'm not able to get rid of the selector targeting the <html> tag.

How we can set the direction to RTL in languages changes of DSpace digital repository

How can we set the direction to RTL in languages change of DSpace digital repository? the second language in our implementation is an RTL language like Persian. rtl.css stylesheet was provided.
We need a solution to assign rtl.css in selecting multiple languages
Sincerely;
This should be possible with a combination of HTML / page level text direction setting, and CSS to switch placement of some page elements.
Here is what I had managed to accomplish while trying some Arabic language display, I think Persian will be very similar? (you might just have to change the 'ar' locale to 'fa', etc.)
This example was tested in Mirage2, but the concepts can apply elsewhere.
In my new theme, I overwrote page-structure.xsl, and I set the whole page document 'dir' attribute to 'rtl' if I detect a locale that wants in (in this case, Arabic)
<!-- switch to rtl if arabic locale -->
<xsl:variable name="active-locale" select="/dri:document/dri:meta/dri:pageMeta/dri:metadata[#element='page'][#qualifier='currentLocale']"/>
<xsl:choose>
<xsl:when test="$active-locale='ar'">
<script><xsl:text>document.documentElement.setAttribute('dir','rtl');</xsl:text></script>
</xsl:when>
<xsl:otherwise>
<script><xsl:text>document.documentElement.setAttribute('dir','ltr');</xsl:text></script>
</xsl:otherwise>
</xsl:if>
That should be enough to sort out the text in the page...
I also made use of a custom bootstrap rtl theme (https://github.com/morteza/bootstrap-rtl) to apply CSS (it's probably similar to the CSS you have?) transformations to flip placement of eg. menu bars or containers to make the page more readable in RTL
To do this, i included the minified CSS in my theme's style folder along with other CSS and added this stylesheet reference to my theme's page-structure.xsl:
<!-- Add Bootstrap 3 RTL support if Arabic locale detected -->
<xsl:if test="/dri:document/dri:meta/dri:pageMeta/dri:metadata[#element='page'][#qualifier='currentLocale']='ar'">
<link rel="stylesheet" href="{concat($theme-path, 'styles/bootstrap-rtl.min.css')}"/>
</xsl:if>
You can use the '.flip' class (as documented on the github page for bootstrap-rtl) to be more specific about flipping certain elements (you'd edit various other XMLUI templates to get those classes in there)... my expertise in how things should look for RTL reading is lacking so I haven't customised individual elements.
Hope this helps! If you're getting stuck with XMLUI / Mirage2 customisation, when it comes to actually applying these changes, you can read https://wiki.duraspace.org/display/DSDOC6x/Mirage+2+Configuration+and+Customization to give some more background.

error adding xml-style sheet to an SVG object inside javascript

I get an error when adding this line of code to my javascript file,
Parse error: syntax error, unexpected T_STRING
var data = "<?xml-stylesheet type='text/css' href='css/main.css' ?>"+
"<svg xmlns='http://www.w3.org/2000/svg' width='800' height='800'>"+
"<foreignObject width='100%' height='100%'>" +
"<div xmlns='http://www.w3.org/1999/xhtml'>"+$("#mainbody").html()
+ "</div></foreignObject></svg>";
the problem disaaperas when I remove this part:
"<?xml-stylesheet type='text/css' href='css/main.css' ?>"
moreever I have the same line in another file, but no problems at all
what could be the problem?
This is a PHP error. You need to escape the <? or ?> sequences, which of course have a special meaning to PHP.
HOWEVER, even after you fix that and make PHP happy, what you are trying to do will not work. When you try to set the "html" property of some DOM node to this data variable you're defining, you'll get a different error saying the DOM string is malformed (or, possibly, the <?xml-stylesheet?> pseudo-instruction will be ignored). That's because xml-stylesheet is something that comes at the beginning of an XML document, not within a textual DOM fragment of the sort that can be assigned to an element's html property. It takes takes effect when an SVG document is displayed, not on an SVG fragment within an HTML page.
What are you trying to accomplish here? The main.css file contains css declarations that are particular just to that fragment of SVG? Why not just include the CSS file in the HEAD of the HTML file?
Another possible solution is to externalize the SVG as a separate file, and include that using an IMG element or something--in that case the <?xml-stylesheet?> pseudo-instruction will work just fine. But that will not allow you to do what you seem to be trying to do with the $("#mainbody") thing--which is...what? To somehow wrap the HTML in SVG? Why?

Invalid/Incorrect html syntax - performance

Let's say we have the following html syntax:
<TABLE width=400, height=300>
<TR>
<TD color=Red>SOME TEXT</TD>
</TR>
</TABLE>
as it can be seen, there is no style used, all tags are written using the uppercase letters. This is invalid. I would like to inform it this kind of incorrect HTML syntax has an influence in web performance?
Additionally, in the code I get from the client, lots of HTML controls are build in code-behind and then injected in the aspx.
How is with performance in such a case?
Uppercase elements are valid in HTML. HTML is case insensitive. While XHTML is not - everything should be lower case.
Upper vs lower case should not affect performance. But lots of CSS inline with the HTML might very well affect performance as often an external CSS will more effectively define the style globally instead of each element.
HTML
http://www.w3.org/TR/html4/about.html#h-1.2.1
Element names are written in uppercase letters (e.g., BODY). Attribute names are written in lowercase letters (e.g., lang, onsubmit). Recall that in HTML, element and attribute names are case-insensitive; the convention is meant to encourage readability.
XHTML
http://www.w3.org/TR/xhtml1/#h-4.2
XHTML documents must use lower case for all HTML element and attribute names. This difference is necessary because XML is case-sensitive e.g. <li> and <LI> are different tags.
The only violation of generic HTML syntax is the comma in <TABLE width=400, height=300>. The comma will probably be taken as part of the attribute value and then ignored. The cost of this error processing is ignorable.
Performance is not an issue here. Basic rendering is.
The height attribute for table is not allowed by HTML specs; though widely supported by browsers, the support is not required (even in HTML5 drafts, which generally require continued support to legacy features) and may be removed in future browsers.
The color attribute for td is not allowed by HTML specs. It is not supported by any browser I know of. So if the intent was to make the text red, it will fail.
The conclusions depend on what you need and can do with the markup. If you cannot adequately change the markup but can inject CSS rules, then you could even fix the non-working non-standard attributes, using e.g.
<style>
[color=Red] { color: red; }
</style>
This would get tedious since you would need e.g. separate rule for each color, and this would not work on some old browsers.
Building HTML controls server-side takes virtually no time at all. In addition, receiving invalid markup will barely affect the rendering time of the browser - however it will affect the display as it will force the client into quirks mode and make a lot of style properties unusable.
Beyond that I'm not sure what exactly you want to know by asking for information on a hypothetical syntax.

How do I stop the XSLT from putting a line break between my TEXTAREA tags

I have in an xsl file a transform that contains <TEXTAREA></TEXTAREA> (no spaces) and when it is transformed the results are
<TEXTAREA>
</TEXTAREA>
I can't find the right properties to stop this from happening.
We are using XslCompiledTransform and XmlTextWriter
Thank you.
XmlTextWriter has a Formatting property that by default is set to Formatting.None. Check that this is the case - if this property were set to Formatting.Indent it would account for the unwanted line-feed.
Use the xsl:strip-space element at the beginning of the styleheet.
<xsl:strip-space elements='TEXTAREA'>
Unwanted whitespace in the output generally comes from one of three places: it's copied from the source document (often by implicitly applying the built-in template rules to whitespace text nodes in the source); or it's generated by using indent="yes", or (rarely, but worth looking for because it's the last place most people think of) it's copied from the stylesheet because someone put xml:space="preserve" in the stylesheet source.

Resources