CSS van Fresnel in wiki code

[LloydRutledge]

CSS vanuit MDDFresnel zal binnen MediaWiki gaan slaan op delen van die wiki, afhankelijk van de context. (Denk aan toepassing op tabellen, kolommen, rijen of cellen).

Je kan Wikipedia gebruiken als voorbeeld. En de Person/BIo infobox in het bijzonder. En die Wikipedia pagina van Tim Berners-Lee in het bijzonder. Hier een elders in deze project waar wiki code gegeneerd wordt. Dus je kan kijken naar de CSS die in de vier plekken op de Wikipedia infobox tabellen gebruikt wordt. En denken hoe je CSS met ons systeem de resultaat op de wiki meer en meer als de Wikipedia infobox kan laten lijken.

[jbachh]

Document toegevoegd aan designmap binnen subversion

[LloydRutledge]

Kan je de links geven voor deze documenten binnen SVN?

[jbachh]

Natuurlijk, het is ABIsvn\source\trunk\FresnelForms\design

[LloydRutledge]

Bedankt. Het lijkt me nuttig als volgend stap om een of meerdere voorbeelden te maken van CSS in Fresnel en de infobox template and form code die Fresnel Forms zou genereren. Met waarschijnlijk test wikipagina's die deze gewenst en verwachte CSS functionaliteit tonen in de weergave.

[jbachh]

OK. Hopelijk kunnen we het daar morgenavond tijdens Scrum ook even over hebben.

From: Lloyd Rutledge [mailto:notifications@github.com] Sent: Sunday, December 07, 2014 10:23 PM To: ABI-Team-30/Fresnel-Forms Cc: jheijning Subject: Re: [Fresnel-Forms] CSS van Fresnel in wiki code (#5)

Bedankt. Het lijkt me nuttig als volgend stap om een of meerdere voorbeelden te maken van CSS in Fresnel en de infobox template and form code die Fresnel Forms zou genereren. Met waarschijnlijk test wikipagina's die deze gewenst en verwachte CSS functionaliteit tonen in de weergave.

— Reply to this email directly or view it on GitHub https://github.com/ABI-Team-30/Fresnel-Forms/issues/5#issuecomment-65955751 .Image removed by sender.

[LloydRutledge]

Nu "should" omdat vanwege nieuwe uitnodigin voor SWCS journal issue. Deze issues is zeer relevant voor de SWCS 2013 paper die voor de journal uitgebreid wordt.

[LloydRutledge]

Maak 3 centrale CSS code in zowel GUI (Alex) als Fresnel (Teun) als wiki (Joop). De centrale CSS is voor (1) alleen alle boxes, (2) alleen alle forms en (3) zowel alle boxes als alle forms.

[jbachh]

Zodra het in fresnel zit, kan ik beginnen met implementeren. Op de testserver staat het idee van de uiteindelijke vorm al.

[LloydRutledge]

Het zit natuurlijk al in de Fresnel ontologie, Joop. Of bedoel je dan in de Fresnel dat de plugin maakt? Je zou volgens mij zelf met een tekst editor (of Protégé direct op de Fresnel triples) de CSS Fresnel test triples waarop je conversie getest kan worden. En dan zijn die ook de basis voor wat de Fresnel export moet maken.

Dat is deel van mijn voorgestelde werkwijze: Eerste wikicode met de hand. Dan Fresnel code met de hand als input in Fresnel2wiki om die wikicode te maken. En dan dat de plugin die Fresnel code kan maken.

Je hoeft dus volgens mij niet op Teun te wachten als je eraan al wilt werken. Zeker als het de W3C Fresnel betreft. Als het een OWF uitbreiding op Fresnel betreft dan moet volgens mij Teun dan wel eerste dat deel van de ontologie eerst ontwerpen.

[jbachh]

Dat klopt natuurlijk. Ik zal dus beginnen met het implementeren van support voor fresnel:resourceStyle, fresnel:propertyStyle, fresnel:labelStyle en fresnel:valueStyle. (in mediawiki was een voorbeeld hiervoor al geschreven)

[TeunTheunissen]

Hallo Joop, in de fresnel generatie zoals ik het aan Alex heb voorgesteld wordt er per lens een groep aangemaakt waaraan de globale formaat definities toegekend kunnen worden. Per lens kunnen dan weer formats gedefinieerd worden waarop onderscheid gemaakt kan worden via de fresnel:purpose tag. een voorbeeld uit de shakespear ontology:

:lit-PersonLensGroup a fresnel:Group; fresnel:containerStyle "ccs"^^fresnel:styleClass ; fresnel:labelStyle "cls"^^fresnel:styleClass ; fresnel:propertyStyle "cps"^^fresnel:styleClass ; fresnel:resourceStyle "crs"^^fresnel:styleClass ; fresnel:valueStyle "cvs"^^fresnel:styleClass .

:lit-PersonLensFormat1 a fresnel:Format ; fresnel:purpose owf:WikiForms; fresnel:containerStyle "ccs1"^^fresnel:styleClass ; fresnel:labelStyle "cls1"^^fresnel:styleClass ; fresnel:propertyStyle "cps1"^^fresnel:styleClass ; fresnel:resourceStyle "crs1"^^fresnel:styleClass ; fresnel:valueStyle "cvs1"^^fresnel:styleClass .

:lit-PersonLensFormat2 a fresnel:Format ; fresnel:purpose owf:InfoBox; fresnel:containerStyle "ccs2"^^fresnel:styleClass ; fresnel:labelStyle "cls2"^^fresnel:styleClass ; fresnel:propertyStyle "cps2"^^fresnel:styleClass ; fresnel:resourceStyle "crs2"^^fresnel:styleClass ; fresnel:valueStyle "cvs2"^^fresnel:styleClass .

Kun je hier wat mee?

[jbachh]

jep, dankjewel. ik ga er mee beginnen en zondag op de vergadering hebben we het er over.

[AlexMekkering]

Ik ben met implementatie van algemene ondersteuning van dit idee begonnen, maar heb naar aanleiding van de opzet hierboven nog een paar (semantische) vragen.

Als ik het goed begrepen heb vanuit de Fresnel Manual:

1. Gelden alle styling properties binnen een Group voor alle Resources (lees class- of instance-domains), Properties, Labels, of Values binnen die groep. Hierdoor zijn wel alle styling properties hierbinnen geldig, maar gedeeltelijk voor lenzen (resourceStyle) en gedeeltelijk voor properties (property-, label- en valueStyle).
2. Gelden styling properties binnen een LensFormat slechts voor een lens (hier dient het class- of instanceFormatDomain nog toegevoegd te worden). Hierdoor zou slechts resourceStyle geldig zijn binnen een LensFormat.
3. Gelden styling properties binnen een PropertyFormat voor properties welke voldoen aan de propertyFormatDomain. Hier zijn dus slechts property- label- en valueStyle geldig,

Daarnaast denk ik dat een fresnel:purpose binnen een Format niet de juiste manier is om het onderscheid te maken, deze is namelijk bedoeld om verschillende output media te ondersteunen. Volgens #30 dienen er aparte Lenzen (voor dezelfde Class) te komen voor de InfoBox en de WikiForms ipv slechts de formaten ervan, dus lijken me aparte Lenzen met elk een fresnel:purpose property in dit geval het meest logisch. Echter hebben we dan nog een apart Format voor een Lens nodig als we de styling info ervoor in de bijbehorende Group (voor elke lens één) kwijt kunnen?

Wanneer @TeunTheunissen en @LloydRutledge het hiermee eens zijn, zal ik:

1. De styling properties van een Lens in de bijbehorende Group stoppen en teruglezen voor het inlezen van die lens.
2. De property-, label- en valueStyle properties uit de Group als default laten gelden voor een property op die lens (heeft echter voorrang op die van de algemene Format voor die property (dus de format welke niet impliciet is gekoppeld aan de LensGroup of expliciet gekoppeld).

[LloydRutledge]

Met (1) en (2) heb ik geen bezwaar maar ik buig voor de Fresnel goeroe Teun over vragen over Fresnel. Wil je #30 dan aanpassen zodat er alleen één lens is voor zowel box als form? Zo ja dan vind ik het zelf prima. Je analyseert en beargumenteert goed hoe het de CSS efficiënter maakt. Ik zie niet hoe deze vereniging problemen zal veroorzaken in Fresnel en de wiki conversie, als Teun en Joop daar ook geen problemen zien.

[TeunTheunissen]

Als goeroe ben ik het met Alex eens. In het geval dat er twee aparte lensen zijn, 1 voor de infobox en 1 voor de form, er geen aparte format definities nodig zijn. De style definities die in de groep voor de betreffende lens gedefinieerd staan zijn voldoende. Daarnaast kan nog per property een formaat gedefinieerd worden indien nodig. Dit betekend dat de gui dus wel de mogelijkheid moet geven om 2 verschillende stylen op te geven. Zowel voor de lens/box als voor de properties, de eerste komt in de lensgroep style definities, de tweede wordt gedefinieerd in de property format definitie. De formaten voor de infobox en form kunnen dan vervallen.

ps. Het mooie van het semantische web is de flexibiliteit dus fresnel.purpose kan mijn inziens prima gebruikt worden om aan te geven waar het formaat geschikt voor is anders dan de output media. Het kan ook gecombineerd worden bv. fresnel.purpose owf:InfoBox, fresnel.purpose :Printer

Vr.gr.TT

[AlexMekkering]

Generic support implemented in r285.

• A Lens's formatting properties are defined by that Lens's fresnel:group.
• Formats and Groups are handled by priority now. The algorithm is defined in 'design/Prioritering van Property Formats.docx'
• fresnel:containerStyle has also been remove, for it isn't used (for now)

@TeunTheunissen could you review this? @jheijning, you can start using getFormattingProperties the same way you did for the labels. i.e. Just call getFormattingProperties(property, lens).get(FRESNEL.VALUESTYLE) to get the most specific valueStyle.

[jbachh]

A question about the priority algorithm: Now all the CSS code from a lower priority gets ignored and replaced with CSS from a higher priority format. Isn't it a problem that you lose previously defined CSS style code? For example, if a lower priority states: style="font-weight: bold" and the higher priority style="color: blue", shouldn't the final CSS code read: style="font-weight: bold; color: blue"? (or in the case of similar properties: style="color:red; color: blue": blue gets the priority in the end). You understand what I mean?

[jbachh]

What a solution could be in fresnel2wiki is to first concat the style properties from the lowest priority format if any, then concat the next priority and so forth, and then paste the entire string in the template row.

[AlexMekkering]

That could be a usefull improvement indeed, because conflicts between CSS items (i.e. 'color:blue; color:red') do not exist when the prioritized Formats are strictly followed. In other words: because CSS is cascading, if we concatenate the CSS of a higher priority Format to the one of the lower priority Format, the higher priority one will always be used by the CSS engine of the browser..

So, we could just concatenate CSS styles (of the same fresnel:xxxStyle) without checking for conflicts. fresnel:label and fresnel:value however should be strictly prioritized, overriding lower priorities.

@LloydRutledge, is this how you'd like the CSS styles to behave in the plugin?

[AlexMekkering]

JenaFresnelUtils.getFormattingProperties(Resource lens) has been added in r288 to ease retrieval of all formatting properties for a Lens (which may reside in several fresnel:Group items). This can be used exactly like the one for properties on a lens: it returns a Map of applicable properties.

[LloydRutledge]

What I understand from this is that fresnel2wiki will concatentate CSS style strings when putting the CSS code in wiki code or HTML code in wiki code. This seems to have the end system behave according to spec, and to introduce no problems. So I approve.

My only question is if determining cascading order by specificity makes this unnecessary. See http://www.w3.org/TR/REC-CSS2/cascade.html#cascading-order and http://www.w3.org/TR/REC-CSS2/cascade.html#specificity . If the higher priority CSS code applies to a more specific part of the HTML as rendered by the wiki then the CSS engine in the browser will process that same priority by leaving the CSS code as is.

However, while the CSS spec defines this in terms of selectors from a separate CSS file, aren't we attaching the CSS directly to elements as style attributes, either directly or (perhaps) indirectly via wiki rendering of HTML? Do browser CSS implementation higher level elements in HTML element nesting get recognized as less specific and thus lower priority? Or are these questions perhaps irrelevant because the rendered wiki display's HTML element nesting doesn't match the corresponding Fresnel anyway? In the last cause, forget my concern and just implement concatenation.

Joop, if such HTML nesting with CSS specificity possibly makes sendse, can you then make small test cases in wiki code to see if CSS specificity-based cascading makes this concatenation unnecessary? Or have you already shown it's needed? This is pretty unimportant so if you find it easier just to implement concatenation than to see if specificity works than feel free to say so and implement concatenation.

[AlexMekkering]

Joop's point was that by concatenating CSS styles from less specific to more specific Formats, no styling information will be lost. In addition, when the same CSS attributes are defined multiple times with different specificity (i.e. a less specific Format states 'color:green' and a more specific Format states 'color:blue'), point 4 of http://www.w3.org/TR/REC-CSS2/cascade.html#cascading-order states that 'if two rules have the same weight, origin and specificity, the latter specified wins.'. So even if CSS specificity isn't explicitly defined, it'll be defined implicitly by the order it appears in the CSS string.

So, by implementing concatenation of the same CSS style of different Formats from less specific to more specific Formats, we keep all styling information and, let SMW decide to use the last style definition in case of conflicting styles, according to the CSS cascading order.

It would indeed be wise to at least check whether SMW behaves as expected before implementing styling this way. @jheijning, could you check this?

[LloydRutledge]

Where is "design/Prioritering van Property Formats.docx"?

[AlexMekkering]

It's in the svn repository: https://svnext.ou.nl/INF_Studenten_ABI_team30/source/trunk/FresnelForms/design/Prioritering%20van%20Property%20Formats.docx

[LloydRutledge]

So this CSS concatenation only happens in Fresnel2wiki as concatenated strings within the generated wiki and HTML code in the XML wiki import? And not in the generation of the Fresnel from the GUI? (Yeah, the later makes little sense; I'm just checking.) And this concatenation only happen where CSS can't handle it through inheritance or selectors or specifiers? Then I understand all this (I think) and see that it would work and also see no objection.

[LloydRutledge]

Feel free to Skype me this afternoon if its quicker.

[jbachh]

Lloyd, you are correct in the above.

I think this proves the concept: {	class=wikitable style="color:green"
This will be green.
- style="color:blue" (this text will not display in the table).
style=""	This will be blue.
style="color:yellow;color:purple"	This will be purple. Color:yellow has no effect.
}

For example, if in the gui, an end-user right-clicked in the lens (not on a specific property), to set the global resource style, label style and so forth for the lens, and enters color:yellow for global value style, then all values should by default have yellow values, i.e. fresnel2wiki will give all value cells style="color:yellow". But if the end-users then for a specific property sets a different value style, in the above example color:purple, color purple will be the style that gets used: color:purple will be concatenated to end of the existing style string instead of replace the style string. The advantage of doing it this way, is that if a user enters text-align:center for global values, then this will not get lost if the end-user sets a specific property's value style to color:purple: the css code will then be: style="text-align:center; color:purple"

[AlexMekkering]

Great, it works as expected! I will implement it this evening then.

[AlexMekkering]

Implemented concatenation of CSS properties in r293. @jheijning, could you check and review this commit? Unit tests are also updated :wink:.

[jbachh]

Due to well-working team-effort: It seems CSS from fresnel (from gui actually) to wiki code has been implemented according to specs!

please review Alex

[jbachh]

support for (css/html for) images, i will get to it soon.

[AlexMekkering]

Works like a Charm, I'm quite impressed by the results! The code looks good and CSS indeed correctly works its way up from Protégé GUI to SMW InfoBox.

[jbachh]

Alex, reviewed your code as well, works as expected. Now also added support for images, please review. Impossible to test functionally in Protege as the change type to Image feature doesn't generate a fresnel:value fresnel:image for the property format in fresnel as expected.

[AlexMekkering]

Review comment

De unit tests voor testFresnelToWiki slagen bij mij niet Deze faalt bij regel 101 omdat de volgorde van resourceStyles voor Lenzen niet geprioriteerd is en dus in willekeurige volgorde kunnen verschijnen (maw prioriteit is hetzelfde, dus maakt het niet uit wie er eerst komt). ipv color:yellow; color:purple is het in mijn geval dus color:purple; color:yellow. Zie ook mijn oplossing hiervoor in JenaFresnelUtilsTest.java vanaf regel 108.

Voor de rest zou ik in Fresnel2wiki.java voor vergelijkingen op equality de vaste waarde voorop zetten, dus bijv in regel 169 (maar ook toe te passen op regel 220):

isImage = FRESNEL.IMAGE.equals(JenaFresnelUtils.getFormattingProperties(prop, lens).get(FRESNEL.VALUE));

ipv

if (JenaFresnelUtils.getFormattingProperties(prop, lens).get(FRESNEL.VALUE) != null) {
    isImage = JenaFresnelUtils.getFormattingProperties(prop, lens).get(FRESNEL.VALUE).equals(FRESNEL.IMAGE);
}

Dit heeft als voordeel dat je niet op null hoeft te checken omdat de vaste waarde altijd bestaat (en dus een equals() methode honoreert).

[AlexMekkering]

Added support for fresnel:image in property formats in r300. Please Review.

[jbachh]

Thanks for the tip! Review: Image support works well up to and including the wiki export generation.

Now I am running into another problem which is that wiki doesn't like it that you put {{{..}}} into html tags it seems, it takes the brackets with the URL for the image into the informbox, preventing correct image display. I am looking for solutions.

[AlexMekkering]

Functionaliteit is ingebouwd dus Issue opgelost! Voor vervolgwerkzaamheden (niet strict CSS) zijn issues #50 en #51 opgevoerd.